RIPE90 proposal to deprecate the RIPE NONAUTH Database
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
Hi, cleaning the NONAUTH database this way sounds like a good idea. - Daniel On 7/18/25 1:09 PM, Job Snijders wrote:
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.
Dear Job,
On 18 Jul 2025, at 13:09, Job Snijders <job@sobornost.net> wrote:
...
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?
From the 'no match' objects, using the prefix and ASN, I found 1,851 of them with a VALID ROA. Regards Ed Shryane RIPE NCC
Hi Job,
On 18 Jul 2025, at 12:39, Edward Shryane <eshryane@ripe.net> wrote:
Dear Job,
On 17 Jul 2025, at 20:23, Job Snijders <job@sobornost.net> wrote:
Dear Ed, ...
* 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.
Unfortunately I was rate-limited when using RDAP across RIRs so I used the GRS mirror databases and the Whois REST API. For each RIR, I queried using the route(6) prefix and the exact and all less specific flag and counted org: references. APNIC: org: reference found for 317 prefixes out of 1512. Top 10 (excluding APNIC itself) : ORG-CTL1-AP 16 ORG-IL3-AP 17 ORG-SXTC1-AP 23 ORG-AW1-AP 25 ORG-CPL3-AP 30 ORG-NSIH1-AP 31 ORG-LTL4-AP 52 ORG-TAL1-AP 64 ORG-ASPL7-AP 126 ORG-BCTC1-AP 285 AFRINIC: org reference found for 37039 out of 37053 prefixes Top 10 (excluding AFRINIC itself) : ORG-TNG3-AFRINIC 637 ORG-ATIA2-AFRINIC 666 ORG-MS5-AFRINIC 809 ORG-SA54-AFRINIC 888 ORG-WOL1-AFRINIC 977 ORG-MA26-AFRINIC 1849 ORG-LE1-AFRINIC 3019 ORG-NO1-AFRINIC 4180 ORG-TD2-AFRINIC 7845 ORG-EM1-AFRINIC 14290 ARIN: org reference found for 6066 out of 6101 prefixes Top 10 (excluding ARIN itself) : PSI 97 VRTL 118 RACKS-8 133 PSI-2 139 ACCENT-10-Z 190 ENSONO 277 AFILI-2 340 CWBL-1 377 CWJM 393 INCAP-5 625 LACNIC: descr reference (no org references) found for all 868 prefixes Top 10 (excluding LACNIC itself) : 8 Prefeitura de Cuiabá 9 ANEXIA SOUTH AMERICA SOCIEDAD ANONIMA 9 LACNIC generated route for DIRECTV COLOMBIA LTDA. 9 Soluciones Favorables 19 DataCorpore Serviços e Representações 25 Emerging Markets Communications de Argentina S.R.L 29 CANTV Servicios, Venezuela 70 PRIVATE LAYER INC 125 UNIVERSIDADE FEDERAL DE MINAS GERAIS 392 Red Cientifica Peruana Regards Ed Shryane RIPE NCC
Hi Ed, People are still using the data. Whether they should or not is a different question. We don't have visibility on the queries that ripe-irrdb consumers issue to other irrdbs, which means that it would be difficult to quantify the impact of withdrawing RIPE-NONAUTH. Having said that, queries can and probably should be directed to authoritative sources rather than continuing the dependence on RIPE-NONAUTH. But we do need to acknowledge that deleting this information will cause different output to irrdb queries, which may have an impact for real-world routing decisions. For this reason, it would be important to clearly document what's going on, somewhere on the ripe.net web site In terms of the specifics:
Should RIPE-NONAUTH Objects Be Returned By Default?
I'd be happy to see a timetable for this to be withdrawn.
Should we continue to support mirroring the NONAUTH database, considering the non-authoritative nature of the data and low rate of updates?
yes, this should be enabled on NTRM as long as the DB exists.
Should RIPE-NONAUTH objects with an exact match in another RIR database be deleted?
yes.
Should we remove any NONAUTH route(6) objects which are not announced? Do they serve any useful purpose?
Yes, after a grace period. It could be argued that "the dfz" is not the only internet, but conversely, the ripe irrdb serves "the dfz". Job Snijders wrote on 18/07/2025 12:09:> * 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.
LGTM. I.e. remove the distinction between valid and invalid, which would leave a RIPE-NONAUTH DB which only documented prefixes which are current on the internet, for which there is no other authoritative information in either RPKI or another auth IRRDB. Open questions: 1. does this apply to exact-match prefixes only, or to prefixes for which there is an authoritative covering prefix, and 2. what to do if/when ripe-nonauth matches the announcement, but not the authoritative IRR route(6) object? It would also be appropriate to announce a final sunset date for the service. Adequate notice (e.g. 1y/3m/1m/deletion date) to registrees via email only. Then delete the remaining objects and terminate the NTRM feed. Nick Edward Shryane wrote on 17/07/2025 17:07:
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
----- 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/
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. I agree that it is a good idea to remove the objects which are already represented in a another authoritative IRR. But I strongly suspect that the remaining records have an operational
Should RIPE-NONAUTH Objects Be Returned By Default? Does it even matter? I expect that the bgpq[34] users are explicitly
On Jul 17, Edward Shryane <eshryane@ripe.net> wrote: (With my IXP operator hat on...) purpose (how many are for legacy ARIN resources?) and should be kept around at least for a while. So I recommend that RIPE NCC starts with the uncontroversial cleanups and then we reassess the situation. listing the sources that they want to use.
Should RIPE-NONAUTH objects with an exact match in another RIR database be deleted? Yes: they are redundant.
Should unrouted RIPE-NONAUTH route(6) objects be deleted? Yes, after a grace period, since they have no practical purpose.
-- ciao, Marco
Hi Ed and WG, I would mostly agree with Nick and Marco here in that we should maybe be quite careful when it comes to what we clean up. The benefits of cleaning up the things we are removing has to be weighed against the quite difficult to predict consequences of the objects disappearing. I think it makes sense to start with cleaning up route(6) objects that exist in another RIR's authoritative IRR. (With appropriate notification when possible along with a grace period) We shouldn't count less specific objects though as some networks will filter based on exact match. I think for the most part we can ignore the aut-nums and as-sets for now. My memory is terrible here but have we have reached out to any of the organisations who have a lot of nonauth objects? (such as Etisalat who seem to have a very significant chunk of them) It would be interesting to know why they have so many objects in the RIPE-NONAUTH database still. -Cynthia On Thu, Jul 17, 2025 at 6:07 PM Edward Shryane <eshryane@ripe.net> wrote:
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
----- 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 all, one of the largest Tier 1 ISP AS3356 is still using it for communicating BGP communities for their ASN for some reason, while those are neither in ARIN nor documented in any other official place. I believe, we should get in touch with them before deprecation, as it is still quite relevant information for a significant part of Net Eng. Thanks Max On 27 July, 2025 19:12 CEST, Cynthia Revström via db-wg <db-wg@ripe.net> wrote: Hi Ed and WG, I would mostly agree with Nick and Marco here in that we should maybe be quite careful when it comes to what we clean up. The benefits of cleaning up the things we are removing has to be weighed against the quite difficult to predict consequences of the objects disappearing. I think it makes sense to start with cleaning up route(6) objects that exist in another RIR's authoritative IRR. (With appropriate notification when possible along with a grace period) We shouldn't count less specific objects though as some networks will filter based on exact match. I think for the most part we can ignore the aut-nums and as-sets for now. My memory is terrible here but have we have reached out to any of the organisations who have a lot of nonauth objects? (such as Etisalat who seem to have a very significant chunk of them) It would be interesting to know why they have so many objects in the RIPE-NONAUTH database still. -Cynthia On Thu, Jul 17, 2025 at 6:07 PM Edward Shryane <eshryane@ripe.net> wrote:
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
----- 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/
----- 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 Max, On Mon, Jul 28, 2025 at 12:03:04PM +0200, Max Emig via db-wg wrote:
one of the largest Tier 1 ISP AS3356 is still using it for communicating BGP communities for their ASN for some reason, while those are neither in ARIN nor documented in any other official place.
I believe, we should get in touch with them before deprecation, as it is still quite relevant information for a significant part of Net Eng.
Their communities are also documented in their own IRR: $ whois -h rr.level3.net -- '-s LEVEL3 AS3356' That aut-num object seems to be more up-to-date than the one in RIPE-NONAUTH: aut-num: AS3356 ... source: RIPE-NONAUTH last-modified: 2023-11-28T20:03:20Z in contrast to: aut-num: AS3356 ... source: LEVEL3 last-modified: 2024-12-05T18:06:14Z Kind regards, Job
Hi Job, good to know, then I have no objections against the deprecation. Thanks Max On 28 July, 2025 12:12 CEST, Job Snijders <job@sobornost.net> wrote: Dear Max, On Mon, Jul 28, 2025 at 12:03:04PM +0200, Max Emig via db-wg wrote:
one of the largest Tier 1 ISP AS3356 is still using it for communicating BGP communities for their ASN for some reason, while those are neither in ARIN nor documented in any other official place. I believe, we should get in touch with them before deprecation, as it is still quite relevant information for a significant part of Net Eng.
Their communities are also documented in their own IRR: $ whois -h rr.level3.net -- '-s LEVEL3 AS3356' That aut-num object seems to be more up-to-date than the one in RIPE-NONAUTH: aut-num: AS3356 ... source: RIPE-NONAUTH last-modified: 2023-11-28T20:03:20Z in contrast to: aut-num: AS3356 ... source: LEVEL3 last-modified: 2024-12-05T18:06:14Z Kind regards, Job
Hi Max, I think your 'spot check' example highlights several aspects of the ongoing discussion: - some information in RIPE-NONAUTH can also be found $elsewhere - RIPE-NONAUTH might be out-of-date compared to $elsewhere - some information might only exists in RIPE-NONAUTH All in all it seems there is some support to start pruning information from the RIPE-NONAUTH dataset that can also be found elsewhere. In this sense we move on from the "prune invalid information" strategy towards a "prune redundant information" strategy. Kind regards, Job
- some information in RIPE-NONAUTH can also be found $elsewhere
in the example, the better data were not in an RIR database. randy
Dear colleagues, Thanks for your feedback, there appears to be support to extend the existing NONAUTH cleanup job as follows: * 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. We will only perform an exact-match (and not less-specific) lookup to match a route(6) in another RIRs database. We will document the cleanup on the DB documentation website: https://docs.db.ripe.net/ We will not cleanup NONAUTH aut-nums or as-sets for now. We will contact maintainers of NONAUTH objects before we delete them. We will later reassess what to do with the remaining NONAUTH objects. DB-WG Co-chairs, please let me know if we can proceed and whether an NWI is needed. Regards Ed Shryane RIPE NCC
On 17 Jul 2025, at 18:07, Edward Shryane <eshryane@ripe.net> wrote:
Dear colleagues, ...
Hi Ed, Specifically regarding the deletion of objects that are RPKI OV valid I could see this causing some issues. (Such as having some providers not implementing RPKI OV and requiring IRR objects) I would like it if the NCC could solicit feedback on this from those who would have objects deleted because of this. If the NCC doesn't get any objections within a reasonable time frame it can continue. In case there are any objections I'd like it if this feedback could be provided to the WG. -Cynthia On Fri, 8 Aug 2025, 16:43 Edward Shryane, <eshryane@ripe.net> wrote:
Dear colleagues,
Thanks for your feedback, there appears to be support to extend the existing NONAUTH cleanup job as follows:
* 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.
We will only perform an exact-match (and not less-specific) lookup to match a route(6) in another RIRs database.
We will document the cleanup on the DB documentation website: https://docs.db.ripe.net/
We will not cleanup NONAUTH aut-nums or as-sets for now.
We will contact maintainers of NONAUTH objects before we delete them.
We will later reassess what to do with the remaining NONAUTH objects.
DB-WG Co-chairs, please let me know if we can proceed and whether an NWI is needed.
Regards Ed Shryane RIPE NCC
On 17 Jul 2025, at 18:07, Edward Shryane <eshryane@ripe.net> wrote:
Dear colleagues, ...
----- 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 Cynthia,
On 8 Aug 2025, at 16:52, Cynthia Revström <me@cynthia.re> wrote:
Hi Ed,
Specifically regarding the deletion of objects that are RPKI OV valid I could see this causing some issues. (Such as having some providers not implementing RPKI OV and requiring IRR objects)
I would like it if the NCC could solicit feedback on this from those who would have objects deleted because of this.
Yes, we will notify maintainer(s) of these objects of our plans and ask them for feedback.
If the NCC doesn't get any objections within a reasonable time frame it can continue. In case there are any objections I'd like it if this feedback could be provided to the WG.
I suggest we can wait until RIPE 91 and provide a summary to the DB-WG by then. In the meantime, we'll put any poposed changes to the existing cleanup on hold.
-Cynthia
Regards Ed Shryane RIPE NCC
participants (8)
-
Cynthia Revström -
Daniel Suchy -
Edward Shryane -
Job Snijders -
Marco d'Itri -
Max Emig -
Nick Hilliard -
Randy Bush