Dear colleagues, Some of you will remember me from my years on the NCC's Database team. This time I am writing from the other side of the table, as a resource holder, with an idea I think is worth the WG's consideration. The ask in one paragraph: let a resource holder optionally tell the RIPE NCC's RDAP service to refer queries for the more-specifics of their space to an RDAP server the holder runs, and let clients optionally follow that referral. Nothing is mandatory on either side. A holder that offers nothing behaves exactly as today, and a client that does not follow simply sees the covering object, as today. It is the RDAP analogue of the reverse DNS delegation we already do with domain: and nserver:. Why this matters: an RDAP walk that starts from the IANA bootstrap (RFC 9224) and reaches https://rdap.db.ripe.net/ stops at the covering allocation. If the holder maintains a large, dynamic set of more-specifics and runs a conformant RDAP server for them, there is no way for the RIPE response to hand the client down to it. The last hop is undiscoverable unless you already know the holder's server exists. RDAP is meant to be walked, not memorised, so that hop ought to be discoverable too. And I should say this is not theoretical for me: we publish per-assignment registration data for our own space from our own RDAP server, and running into exactly this gap is what prompted this mail. The real prize, I think, is registration data hygiene. A holder with a lot of assignment activity has two poor options today. Register nothing below the allocation, which leaves coarse, unhelpful data for abuse handling, research and routing. Or bulk-load large numbers of assignment objects that start drifting out of date the day they land, which means stale data and central database bloat. An optional referral to the place where the data is actually maintained gives the community accurate, current, granular registration data served from the source, keeps the central database lean, and preserves an unbroken, machine-walkable chain from the bootstrap to the exact object. It rewards holders for publishing good, live data rather than penalising them for it. The principle is not new for us, only the object of it is. Registrants already maintain their own sub-allocation and assignment data directly. Reverse DNS for the same space is already delegated to the holder's nameservers. And the WG has handled referral concepts before: we retired referral-by: at RIPE 68, though that was an authentication-time mechanism that had stopped earning its keep, which is a different animal from a data-locality referral, and domain referrals go back to the late-90s threads on this list. What has changed is that the standards now express this cleanly, so there is little to invent: * RFC 7480 section 5.2 already lets a server that is not authoritative answer with a 30x and a Location header. The redirect primitive exists. * RFC 9910 (RDAP RIR Search, Standards Track, January 2026) defines the rdap-up and rdap-down relations for navigating the number hierarchy, and rdap.db.ripe.net already emits these today. An rdap-down or related link to the holder's base URL is a natural carrier for the referral, with the holder's server publishing rdap-up back to the RIPE object so the hierarchy stays consistent and loop-safe. * regext is actively working on explicit RDAP referrals right now (draft-ietf-regext-rdap-referrals, "Explicit RDAP Redirects", -04, July 2026): a client can ask to be redirected straight to a related RDAP record, and the draft's own examples already cover IP space. It is early, but it is the natural vehicle for the down-referral, and IP-space input from this WG would land at exactly the right time. So the genuinely new part is a member-facing, opt-in way to register that base URL (scoped strictly to the holder's own space, TLS only), plus the NCC emitting an already-standardised referral. Where I would love the WG's steer: is there appetite for an optional, member-configurable RDAP referral for more-specifics, built on the referrals work above rather than anything bespoke? If there is, I am glad to take it forward as a concrete RIPE NCC feature request and/or a slot at the next db-wg session, and to keep it aligned with the NRO and regext so it stays consistent across RIRs. I can also prototype the down-referral against a live, conformant server that already publishes the up link back to the RIPE object. All the best, Kaveh
Hi Kaveh, On 6 Jul 2026, at 11:12, Kaveh Ranjbar via db-wg <db-wg@ripe.net> wrote: […]
The real prize, I think, is registration data hygiene. A holder with a lot of assignment activity has two poor options today. Register nothing below the allocation, which leaves coarse, unhelpful data for abuse handling, research and routing. Or bulk-load large numbers of assignment objects that start drifting out of date the day they land, which means stale data and central database bloat. An optional referral to the place where the data is actually maintained gives the community accurate, current, granular registration data served from the source, keeps the central database lean, and preserves an unbroken, machine-walkable chain from the bootstrap to the exact object. It rewards holders for publishing good, live data rather than penalising them for it.
It sounds like a great idea but I don’t understand this part. Why would a resource holder not prefer to have their IPAM synchronise what it knows to be true with the RIPE Database instead of spending money on building and maintaining some infrastructure? Yes, I’m assuming that anyone who wants to run their own RDAP server has an IPAM of some kind. Thanks, Leo
Hi Leo, Good to hear from you, and a fair challenge. You are right that for many holders IPAM-to-RIPE synchronisation is the right answer, and nothing in this proposal takes that path away. The referral is for the cases where sync stops working well, and I think those cases are becoming more common: 1. Update rate. Our assignments are created and retired programmatically, some of them living minutes. Syncing that into the central database means a high-frequency stream of writes for objects that may be gone before the next consumer ever reads them, and there is always a staleness window between what the IPAM knows and what the database serves. A referral serves the live answer at read time instead of pushing state at write time. 2. Community cost. Every synced assignment is an object the NCC stores, indexes and serves for everyone. AGGREGATED-BY-LIR exists precisely because the community preferred not to carry every assignment centrally. The referral keeps that lean default and adds only a pointer to where the detail lives. 3. Expressiveness. The holder's RDAP can carry per-assignment detail that does not map cleanly onto inetnum attributes (richer entities, operational metadata, extensions). Central sync caps the published data at what the central schema can express. On the cost point, I agree nobody should build infrastructure just for this. A holder operating at this scale already runs the authoritative source, and an RDAP view over an IPAM is a thin read-only front end. Once regext standardises the redirect I would expect IPAM products to grow it as a feature, rather than each holder building something bespoke. And because it is opt-in on both sides, holders for whom sync is cheaper simply keep syncing; nothing is taken away from them. So: sync where it fits, referral where the data moves faster than sync can follow. The proposal only adds the second option. All the best, Kaveh On Mon, Jul 06, 2026 11:21 AM, Leo Vegoda <leo@vegoda.org> wrote:
Hi Kaveh,
On 6 Jul 2026, at 11:12, Kaveh Ranjbar via db-wg <db-wg@ripe.net> wrote:
[…]
The real prize, I think, is registration data hygiene. A holder with a lot of assignment activity has two poor options today. Register nothing below the allocation, which leaves coarse, unhelpful data for abuse handling, research and routing. Or bulk-load large numbers of assignment objects that start drifting out of date the day they land, which means stale data and central database bloat. An optional referral to the place where the data is actually maintained gives the community accurate, current, granular registration data served from the source, keeps the central database lean, and preserves an unbroken, machine-walkable chain from the bootstrap to the exact object. It rewards holders for publishing good, live data rather than penalising them for it.
It sounds like a great idea but I don’t understand this part.
Why would a resource holder not prefer to have their IPAM synchronise what it knows to be true with the RIPE Database instead of spending money on building and maintaining some infrastructure? Yes, I’m assuming that anyone who wants to run their own RDAP server has an IPAM of some kind.
Thanks,
Leo
Hi Kaveh, Just trying to better understand the use case, some questions come to mind: Are you able to predict the time length those assignments exist? What type of assignments exist only for a few minutes? If it is so short lived who is expected to query during that timespan? Are the assignments for /27 to /32 prefixes or >/26? Also IPv6? Is this something voluntary, some extra info you/others *want* to publish that is not required to be in the db by any policy? Do you think there should be some availability requirements for the referral? In ARIN land there are a lot of less than working referrals. Best, Radu On 7/6/2026 2:32 PM, Kaveh Ranjbar via db-wg wrote:
Hi Leo,
Good to hear from you, and a fair challenge.
You are right that for many holders IPAM-to-RIPE synchronisation is the right answer, and nothing in this proposal takes that path away. The referral is for the cases where sync stops working well, and I think those cases are becoming more common:
1. Update rate. Our assignments are created and retired programmatically, some of them living minutes. Syncing that into the central database means a high-frequency stream of writes for objects that may be gone before the next consumer ever reads them, and there is always a staleness window between what the IPAM knows and what the database serves. A referral serves the live answer at read time instead of pushing state at write time.
2. Community cost. Every synced assignment is an object the NCC stores, indexes and serves for everyone. AGGREGATED-BY-LIR exists precisely because the community preferred not to carry every assignment centrally. The referral keeps that lean default and adds only a pointer to where the detail lives.
3. Expressiveness. The holder's RDAP can carry per-assignment detail that does not map cleanly onto inetnum attributes (richer entities, operational metadata, extensions). Central sync caps the published data at what the central schema can express.
On the cost point, I agree nobody should build infrastructure just for this. A holder operating at this scale already runs the authoritative source, and an RDAP view over an IPAM is a thin read-only front end. Once regext standardises the redirect I would expect IPAM products to grow it as a feature, rather than each holder building something bespoke. And because it is opt-in on both sides, holders for whom sync is cheaper simply keep syncing; nothing is taken away from them.
So: sync where it fits, referral where the data moves faster than sync can follow. The proposal only adds the second option.
All the best, Kaveh
On Mon, Jul 06, 2026 11:21 AM, Leo Vegoda <leo@vegoda.org <mailto:leo@vegoda.org>> wrote:
Hi Kaveh,
On 6 Jul 2026, at 11:12, Kaveh Ranjbar via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote:
[…]
> The real prize, I think, is registration data hygiene. A holder with a lot of assignment activity has two poor options today. Register nothing below the allocation, which leaves coarse, unhelpful data for abuse handling, research and routing. Or bulk- load large numbers of assignment objects that start drifting out of date the day they land, which means stale data and central database bloat. An optional referral to the place where the data is actually maintained gives the community accurate, current, granular registration data served from the source, keeps the central database lean, and preserves an unbroken, machine-walkable chain from the bootstrap to the exact object. It rewards holders for publishing good, live data rather than penalising them for it. >
It sounds like a great idea but I don’t understand this part.
Why would a resource holder not prefer to have their IPAM synchronise what it knows to be true with the RIPE Database instead of spending money on building and maintaining some infrastructure? Yes, I’m assuming that anyone who wants to run their own RDAP server has an IPAM of some kind.
Thanks,
Leo
----- 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 Radu, Good questions, and the concrete answers probably explain the proposal better than my original mail did, so thank you. Lifetime predictability: some of them, not all. In our deployment every AI agent gets its own IPv6 /128 as its network identity. Some agents are long-lived residents; many are created for one task or one session and retired when it ends. For the session-shaped ones we know the order of magnitude at creation time; for the rest the end is only known when it happens. What lives only minutes: exactly those, an agent spun up for one job, egressing from its own /128 for the duration, then gone. The same shape is appearing in ephemeral compute generally; we are just an early and extreme case of it. Who queries during that window: the counterparties the agent talks to while it is alive. A service receiving a connection from one of our /128s can ask "who is this, and who answers for it" at connection time, with RDAP as one leg of that check alongside reverse DNS. So queries are concentrated exactly inside the assignment's lifetime, which is why read-time referral fits better than write-time sync. And after the fact, a holder can choose to keep serving the historical record of what was assigned when, something the central database never carried at this granularity. Sizes: in our case IPv6 only, /128 per agent, out of our own allocation. The mechanism itself is size- and family-agnostic; nothing in it assumes a prefix length. Voluntary: precisely. At this granularity nothing requires these assignments to be in the database; aggregation exists for that reason. This is information a holder wants to publish because it makes their infrastructure legible to the rest of the internet. The aim of the proposal is to make that voluntary publication useful instead of penalising it with bulk-load and drift. Availability requirements: yes, and thank you for the ARIN reminder; broken referrals are worse than no referrals. I would make emission conditional: the NCC validates the designated endpoint before publishing the referral and re-validates periodically, withdrawing it if it rots. And because the referral is advisory, a client that gets nothing from the holder's server still has the covering object from the NCC, so the failure mode is exactly today's behaviour, never worse. All the best, Kaveh On Mon, Jul 06, 2026 12:57 PM, Radu Anghel via db-wg <db-wg@ripe.net> wrote:
Hi Kaveh,
Just trying to better understand the use case, some questions come to mind:
Are you able to predict the time length those assignments exist?
What type of assignments exist only for a few minutes?
If it is so short lived who is expected to query during that timespan?
Are the assignments for /27 to /32 prefixes or >/26? Also IPv6?
Is this something voluntary, some extra info you/others *want* to publish that is not required to be in the db by any policy?
Do you think there should be some availability requirements for the referral? In ARIN land there are a lot of less than working referrals.
Best,
Radu
On 7/6/2026 2:32 PM, Kaveh Ranjbar via db-wg wrote:
Hi Leo,
Good to hear from you, and a fair challenge.
You are right that for many holders IPAM-to-RIPE synchronisation is the right answer, and nothing in this proposal takes that path away. The referral is for the cases where sync stops working well, and I think those cases are becoming more common:
1. Update rate. Our assignments are created and retired programmatically, some of them living minutes. Syncing that into the central database means a high-frequency stream of writes for objects that may be gone before the next consumer ever reads them, and there is always a staleness window between what the IPAM knows and what the database serves. A referral serves the live answer at read time instead of pushing state at write time.
2. Community cost. Every synced assignment is an object the NCC stores, indexes and serves for everyone. AGGREGATED-BY-LIR exists precisely because the community preferred not to carry every assignment centrally. The referral keeps that lean default and adds only a pointer to where the detail lives.
3. Expressiveness. The holder's RDAP can carry per-assignment detail that does not map cleanly onto inetnum attributes (richer entities, operational metadata, extensions). Central sync caps the published data at what the central schema can express.
On the cost point, I agree nobody should build infrastructure just for this. A holder operating at this scale already runs the authoritative source, and an RDAP view over an IPAM is a thin read-only front end. Once regext standardises the redirect I would expect IPAM products to grow it as a feature, rather than each holder building something bespoke. And because it is opt-in on both sides, holders for whom sync is cheaper simply keep syncing; nothing is taken away from them.
So: sync where it fits, referral where the data moves faster than sync can follow. The proposal only adds the second option.
All the best, Kaveh
On Mon, Jul 06, 2026 11:21 AM, Leo Vegoda <leo@vegoda.org <mailto:leo@vegoda.org>> wrote:
Hi Kaveh,
On 6 Jul 2026, at 11:12, Kaveh Ranjbar via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote:
[…]
> The real prize, I think, is registration data hygiene. A holder with a lot of assignment activity has two poor options today. Register nothing below the allocation, which leaves coarse, unhelpful data for abuse handling, research and routing. Or bulk- load large numbers of assignment objects that start drifting out of date the day they land, which means stale data and central database bloat. An optional referral to the place where the data is actually maintained gives the community accurate, current, granular registration data served from the source, keeps the central database lean, and preserves an unbroken, machine-walkable chain from the bootstrap to the exact object. It rewards holders for publishing good, live data rather than penalising them for it. >
It sounds like a great idea but I don’t understand this part.
Why would a resource holder not prefer to have their IPAM synchronise what it knows to be true with the RIPE Database instead of spending money on building and maintaining some infrastructure? Yes, I’m assuming that anyone who wants to run their own RDAP server has an IPAM of some kind.
Thanks,
Leo
----- 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/
participants (3)
-
Kaveh Ranjbar -
Leo Vegoda -
Radu Anghel