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-Operational-Update.pdf
(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/
