Dear colleagues, At RIPE90 I presented a proposal to deprecate the RIPE-NONAUTH database: https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-Op... (slide 20) 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 has only reduced in size by about 10% since it was created in 2018. The existing cleanup jobs and maintainers are not deleting much data. Ruediger Volk pointed out that ARIN had only very recently introduced their NONAUTH database, so it was a very short-term temporary source, and that does not predict anything about the longstanding data that has been split out into RIPE-NONAUTH. He suggested that the RIPE NCC analyse whether something that’s supposed to go away is still being used, or else there is a pretty big danger that someone is actually depending on it. I now present some analysis of the RIPE-NONAUTH database for review. Perhaps we should not retire the RIPE-NONAUTH database completely as we don't know how it is being used, but we could take action to further reduce its size. Your feedback is appreciated. Should RIPE-NONAUTH Objects Be Returned By Default? --------------------------------------------------- The RIPE-NONAUTH database is included by default in Whois queries. This means that any matching object in the RIPE-NONAUTH database is automatically returned in the Whois query response. That includes as-set, aut-num, route and route6 object types. For example, when querying for "AS2561", the matching aut-num object in the RIPE-NONAUTH database is returned. Additionally, *related* matching objects in the RIPE-NONAUTH database will also be returned by default. For example, when querying for the IPv4 prefix "200.30.0.0/18", the related route object "200.30.0.0/18AS5511" in the RIPE-NONAUTH database is returned. We found that RIPE-NONAUTH objects are returned only in a small number of cases (about 0.006% of all queries), but there is a risk that clients will inadvertently trust non-authoritative data if the "source:" attribute is not checked. As a workaround, clients can use the "-s RIPE" flag to only query the RIPE database. Should objects in the RIPE-NONAUTH database continue to be returned by default? Near Realtime Mirroring (NRTM) ------------------------------ Approximately 20% of NRTM requests query for updates to the NONAUTH database. Should we continue to support mirroring the NONAUTH database, considering the non-authoritative nature of the data and low rate of updates? Should RIPE-NONAUTH objects with an exact match in another RIR database be deleted? ----------------------------------------------------------------------------------- Approximately 31,930 out of 45,754 route(6) objects in the RIPE-NONAUTH database have a matching route(6) object (i.e. matching origin ASN and exactly matching or less-specific prefix) in another RIR’s IRR database. Approximately 13 out of 67 as-set objects in the RIPE-NONAUTH database have an exactly matching as-set in another RIR’s database. Approximately 1,840 out of 2,073 aut-num objects in the RIPE-NONAUTH database have an exactly matching aut-num object in another RIR’s database. Should we delete RIPE-NONAUTH objects which duplicate identically named objects in an authoritative RIR’s database? Should unrouted RIPE-NONAUTH route(6) objects be deleted? --------------------------------------------------------- Approximately 33,912 out of 44,647 RIPE-NONAUTH route(6) objects appear in the global routing table (as of 12th July). Should we remove any NONAUTH route(6) objects which are not announced? Do they serve any useful purpose? Regards Ed Shryane RIPE NCC
Dear Ed, On Thu, Jul 17, 2025 at 06:07:07PM +0200, Edward Shryane wrote:
The RIPE-NONAUTH database has only reduced in size by about 10% since it was created in 2018. The existing cleanup jobs and maintainers are not deleting much data.
Perhaps nitpicking - but I thought back in October 2018 [1] RIPE-NONAUTH contained ~ 69,178 'route:' objects, and nowadays 45,601, a 34% hefty decrease! Sadly, shaving off only 34% is less than I was hoping for back in 2018... Would it be feasible for you to produce a more statistics and insights on what exactly is contained in RIPE-NONAUTH? * which of the other four RIRs is supposed to manage what % of route/route6 objects? * how many distinct entities does the space belong to? (perhaps hard to answer, perhaps be found via RDAP?) * How many route/route6 objects have an exact, more-specific, or less-specific match in one of the four other RIR-managed IRR databases? It seems that roughly 15,619 'route:' objects are RPKI-OV VALID. Would it make sense to extend RIPE-731 to also cleanup RPKI-OV VALID objects (because the routing intentions for those resources are also asserted in a cryptographicly validated database... ? But then what to do with the remaining 28,998 'route:' objects? Kind regards, Job [1]: https://mailman.ripe.net/archives/list/routing-wg@ripe.net/message/OVLYCURRI...
Ruediger Volk pointed out that ARIN had only very recently introduced their NONAUTH database, so it was a very short-term temporary source, and that does not predict anything about the longstanding data that has been split out into RIPE-NONAUTH. He suggested that the RIPE NCC analyse whether something that’s supposed to go away is still being used, or else there is a pretty big danger that someone is actually depending on it.
I now present some analysis of the RIPE-NONAUTH database for review. Perhaps we should not retire the RIPE-NONAUTH database completely as we don't know how it is being used, but we could take action to further reduce its size. Your feedback is appreciated.
Should RIPE-NONAUTH Objects Be Returned By Default? ---------------------------------------------------
The RIPE-NONAUTH database is included by default in Whois queries.
This means that any matching object in the RIPE-NONAUTH database is automatically returned in the Whois query response. That includes as-set, aut-num, route and route6 object types. For example, when querying for "AS2561", the matching aut-num object in the RIPE-NONAUTH database is returned.
Additionally, *related* matching objects in the RIPE-NONAUTH database will also be returned by default. For example, when querying for the IPv4 prefix "200.30.0.0/18", the related route object "200.30.0.0/18AS5511" in the RIPE-NONAUTH database is returned.
We found that RIPE-NONAUTH objects are returned only in a small number of cases (about 0.006% of all queries), but there is a risk that clients will inadvertently trust non-authoritative data if the "source:" attribute is not checked. As a workaround, clients can use the "-s RIPE" flag to only query the RIPE database.
Should objects in the RIPE-NONAUTH database continue to be returned by default?
Near Realtime Mirroring (NRTM) ------------------------------
Approximately 20% of NRTM requests query for updates to the NONAUTH database.
Should we continue to support mirroring the NONAUTH database, considering the non-authoritative nature of the data and low rate of updates?
Should RIPE-NONAUTH objects with an exact match in another RIR database be deleted? -----------------------------------------------------------------------------------
Approximately 31,930 out of 45,754 route(6) objects in the RIPE-NONAUTH database have a matching route(6) object (i.e. matching origin ASN and exactly matching or less-specific prefix) in another RIR’s IRR database.
Approximately 13 out of 67 as-set objects in the RIPE-NONAUTH database have an exactly matching as-set in another RIR’s database.
Approximately 1,840 out of 2,073 aut-num objects in the RIPE-NONAUTH database have an exactly matching aut-num object in another RIR’s database.
Should we delete RIPE-NONAUTH objects which duplicate identically named objects in an authoritative RIR’s database?
Should unrouted RIPE-NONAUTH route(6) objects be deleted? ---------------------------------------------------------
Approximately 33,912 out of 44,647 RIPE-NONAUTH route(6) objects appear in the global routing table (as of 12th July).
Should we remove any NONAUTH route(6) objects which are not announced? Do they serve any useful purpose?
Regards Ed Shryane RIPE NCC
----- 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/
Dear Job,
On 17 Jul 2025, at 20:23, Job Snijders <job@sobornost.net> wrote:
Dear Ed,
On Thu, Jul 17, 2025 at 06:07:07PM +0200, Edward Shryane wrote:
The RIPE-NONAUTH database has only reduced in size by about 10% since it was created in 2018. The existing cleanup jobs and maintainers are not deleting much data.
Perhaps nitpicking - but I thought back in October 2018 [1] RIPE-NONAUTH contained ~ 69,178 'route:' objects, and nowadays 45,601, a 34% hefty decrease!
You are correct! Apologies, I mis-remembered the original size of the NONAUTH database. As you mentioned there are now 45,601 route(6) RIPE-NONAUTH objects, and in addition 2,066 aut-num and 67 as-set objects.
Sadly, shaving off only 34% is less than I was hoping for back in 2018...
Which equates to a few thousand objects deleted yearly since 2018.
Would it be feasible for you to produce a more statistics and insights on what exactly is contained in RIPE-NONAUTH?
* which of the other four RIRs is supposed to manage what % of route/route6 objects?
I searched today by route(6) *prefix* (only) compared to the latest NRO combined delegated stats to find which delegated space is supposed to manage what % of route(6) objects (out of 45,601 total) : * AFRINIC: 37,053 * APNIC: 1,512 * ARIN: 6,102 * LACNIC: 868 * No match (e.g. reserved space) : 66
* how many distinct entities does the space belong to? (perhaps hard to answer, perhaps be found via RDAP?)
I will check the IRR mirror databases and group by organisation if possible, or maintainer if not. This will take a bit more time.
* How many route/route6 objects have an exact, more-specific, or less-specific match in one of the four other RIR-managed IRR databases?
When I previously searched for a matching *route(6) object* in the other RIR's IRR mirror databases (with exact match ASN and exact or less-specific matching prefix) I found : * AFRINIC: 29,847 * APNIC: 302 * ARIN: 1,604 * LACNIC: 56 * No match : 13,824
It seems that roughly 15,619 'route:' objects are RPKI-OV VALID.
Would it make sense to extend RIPE-731 to also cleanup RPKI-OV VALID objects (because the routing intentions for those resources are also asserted in a cryptographicly validated database... ? But then what to do with the remaining 28,998 'route:' objects?
We can extend RIPE-731 to include VALID objects, if the DB-WG agrees. Can this be done as a new NWI ? Is it enough to expect RPKI adoption to increase to eventually cover all delegated space, to eventually cleanup the RIPE-NONAUTH database? Could we additionally implement a new cleanup by deleting RIPE-NONAUTH route(6) objects if matching a route(6) object in an RIR's authoritative database?
Kind regards,
Job
[1]: https://mailman.ripe.net/archives/list/routing-wg@ripe.net/message/OVLYCURRI...
Dear Ed, Perhaps going forward, the guiding principle should be: "if info for a resource in RIPE-NONAUTH also available is in a 'better quality' location, then there is no need for the object continue to exist in the non-authoritative RIPE-NONAUTH database." IMHO 'better quality' locations would be: * RPKI ROAs * other RIR-managed IRR databases
* How many route/route6 objects have an exact, more-specific, or less-specific match in one of the four other RIR-managed IRR databases?
When I previously searched for a matching *route(6) object* in the other RIR's IRR mirror databases (with exact match ASN and exact or less-specific matching prefix) I found :
* AFRINIC: 29,847 * APNIC: 302 * ARIN: 1,604 * LACNIC: 56 * No match : 13,824
Of the 'no match' objects, how many are RPKI valid?
We can extend RIPE-731 to include VALID objects, if the DB-WG agrees. Can this be done as a new NWI ?
Perhaps the DB-WG chairs can chime in on procedures?
Is it enough to expect RPKI adoption to increase to eventually cover all delegated space, to eventually cleanup the RIPE-NONAUTH database?
I expect there to be a 'long tail', and there is no proof of termination.
Could we additionally implement a new cleanup by deleting RIPE-NONAUTH route(6) objects if matching a route(6) object in an RIR's authoritative database?
That sounds very reasonable to me. * Continue to delete RPKI-OV INVALID objects (the RIPE-731 mandate) * Delete RIPE-NONAUTH route(6) objects when they become RPKI-OV VALID * Delete RIPE-NONAUTH route(6) objects when they become *covered* by a route(6) object in another RIR's auth database. In all cases the RIPE-NONAUTH object deletion would be the consequence of 'a better source of information' existing elsewhere. Kind regards, Job
participants (2)
-
Edward Shryane -
Job Snijders