Hi Dominik,
I believe changing the policy will lead to exactly more of 1 - change won't be registered with the NCC in order for the resource not to lose its legacy status.
This behavior is an anti-pattern and it also goes explicitly against the RIPE NCC process for legacy resource transfers. Hopefully, anyone engaging in these practices understands the risks they are assuming (for them and their customers if they are a service provider) by doing so. For clarity, this policy does not aim to affect transfers among LIRs within the same member account - understanding this would be effectively like M&A/organization restructure cases, which we understand can happen among higher ed and research entities that tend to be legacy resource holders too. The NCC would clarify this in the impact analysis report.
This is significant especially that these changes don't have to be registered in order to be able to use the space - i.e. be creating route objects in alternate DBs.
This too is an anti-pattern we aim to prevent and it hinders RPKI adoption.
For that reason I oppose the proposal. If this is more of "extra work required" type of issue - then let's solve it by putting the correct price tag on it.
This portion will be addressed by the proposed charging scheme models that the NCC is working on presenting soon, following the Charging Scheme Task Force report. However, incentives will not be enough to stop certain actors from exploiting this loophole in RIPE policy. Thank you, Clara On 10/30/25, 9:43 AM, "address-policy-wg-request@ripe.net <mailto:address-policy-wg-request@ripe.net>" <address-policy-wg-request@ripe.net <mailto:address-policy-wg-request@ripe.net>> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Send address-policy-wg mailing list submissions to address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net> To subscribe or unsubscribe via email, send a message with subject or body 'help' to address-policy-wg-request@ripe.net <mailto:address-policy-wg-request@ripe.net> You can reach the person managing the list at address-policy-wg-owner@ripe.net <mailto:address-policy-wg-owner@ripe.net> When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status (Dominik Nowacki) ---------------------------------------------------------------------- Message: 1 Date: Thu, 30 Oct 2025 14:41:09 +0000 From: Dominik Nowacki <dominik@clouvider.co.uk <mailto:dominik@clouvider.co.uk>> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status To: "address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net>" <address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net>> Message-ID: <DB9PR10MB49710786C4D9F9386DDD1D89F2FBA@DB9PR10MB4971.EURP <mailto:DB9PR10MB49710786C4D9F9386DDD1D89F2FBA@DB9PR10MB4971.EURP> RD10.PROD.OUTLOOK.COM> Content-Type: multipart/alternative; boundary="_000_DB9PR10MB497107 86C4D9F9386DDD1D89F2FBADB9PR10MB4971EURP_" Dear Colleagues, I agree with Max. We don't quite have a horse in this race. Clouvider has 1x legacy subnet and is a member of the RIPE NCC regardless. We use it pretty much in the same way as if it was a PA. Clara,
1 Keeping legacy status when the resources are no longer held by the organization that received these pre-RIR administration is not really keeping the database accurate/up-to-date.
I believe changing the policy will lead to exactly more of 1 - change won't be registered with the NCC in order for the resource not to loose its legacy status. This is significant especially that these changes don't have to be registered in order to be able to use the space - i.e. be creating route objects in alternate DBs. For that reason I oppose the proposal. If this is more of "extra work required" type of issue - then let's solve it by putting the correct price tag on it. Kind Regards, Dominik ________________________________ From: Wade, Clara via address-policy-wg <address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net>> Sent: 30 October 2025 14:29 To: Max Emig <ripe@emigm.ax <mailto:ripe@emigm.ax>> Cc: address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net> <address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net>>; peter.hessler@zayo.com <mailto:peter.hessler@zayo.com> <peter.hessler@zayo.com <mailto:peter.hessler@zayo.com>> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status Hi Max, I’m a little confused by the counter-argument here. Could you clarify how you believe this proposal would this lead to out-of-date data and less RPKI adoption? 1. Keeping legacy status when the resources are no longer held by the organization that received these pre-RIR administration is not really keeping the database accurate/up-to-date. 2. Legacy resource holders by default do not have access to RPKI. (You may get access by signing an agreement with the NCC, but unless you do, RPKI services are not included in the basic package offered to legacy resource holders who are not members.) Thank you, Clara From: Max Emig <ripe@emigm.ax <mailto:ripe@emigm.ax>> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad@amazon.com <mailto:clarawad@amazon.com>> Cc: "address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net>" <address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net>>, "peter.hessler@zayo.com <mailto:peter.hessler@zayo.com>" <peter.hessler@zayo.com <mailto:peter.hessler@zayo.com>> Subject: RE: [EXTERNAL] [address-policy-wg] Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Good evening all, I oppose this policy proposal as it may lead to an increase on out-of-date data and less RPKI adoption. However, I would support adding a fee or another disincentive for keeping legacy status. Thanks Max On 27 October, 2025 17:12 CET, "Wade, Clara via address-policy-wg" <address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net>> wrote: Hello everyone, Following the suggestion of the RIPE NCC, we are seeking early feedback on an upcoming policy proposal we currently have in draft status. As mentioned last week after the Registration Services update from Marco at the AP-WG session - Peter Hessler and I, members of the now concluded Charging Scheme Task Force, are drafting a policy proposal to clarify the non-transferability of legacy status to address the issues of increasing overhead for the RIPE NCC, increasing market speculation around a scarce resource and its impact on the adoption of best practices like RPKI. Our proposal will modify these existing policies: 1. “RIPE Resource Transfer Policies” (RIPE-807) with additional clarifications in the Transfer Restrictions section and the Inter-RIR policy section. M&A/org restructuring transfers will be explicitly excluded. 2. “RIPE NCC Services to Legacy Internet Resource Holders” (RIPE-639) with modifications to remove the language implying new holders can keep legacy status after transfer. For background, legacy status was meant to indicate when an Internet resource had been directly assigned to the holder by IANA, before the RIRs were established. As such, ARIN, LACNIC and AFRINIC policies dictate that IPv4 legacy resources will no longer be regarded as legacy resources after a policy transfer takes place (excluding M&A transfers). RIPE is the only RIR that currently allows the recipient of a legacy transfer the ability to inherit the legacy status that was assigned to the original holder by IANA. This is currently being used as a loophole by certain actors to opt out of having a contractual relationship with the RIPE NCC in order to circumvent: 1. RIPE registration services fees. 2. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 3. Needs-based inter-RIR transfer policy utilization requirements in the case of transfers from another RIR to a recipient of a legacy resource transfer in the RIPE region. Following the publication of the Report of the RIPE NCC Charging Scheme Task Force, the membership learned that the RIPE NCC currently needs to dedicate a 0.5FTE to process legacy transfers. There are currently around 2,400 legacy resources held by 1,600 holders with no contractual relationship with the RIPE NCC (neither direct nor via a sponsor). That is around 40M IPs total or 5% of RIPE IPv4 space. In the last four years, NCC staff have processed between 370-280 legacy transfers per year, of which roughly a third do not involve a party with a contractual relationship with the NCC. Legacy transfers are more labor-intensive than other transfer types because the due diligence process requires the Registration Services team to manually source and verify pertaining documentation without the benefits of the automated processes for standard allocations. Legacy transfers take an average seven working hours to process when neither party has a contractual relationship with the NCC (around a third of legacy transfers), and six working hours to process when the parties have a contractual relationship with the NCC. If resources lost their legacy status after a transfer, these would then become standard allocations and staff could leverage enhanced compliance checks and automated processes to facilitate any future updates/transfers. These just take 1-3 working hours to process instead. Given that the task force was deemed out of scope for a policy change to address this gap, this is being brought to the attention of the Address Policy Working Group for action. If there are any concerns, questions or considerations you would like to bring up before we submit this proposal for discussion in the next week or two, we would really appreciate hearing from you so we can address these and/or incorporate them. Thanks in advance, Clara Wade -------------- next part -------------- A message part incompatible with plain text digests has been removed ... Name: not available Type: text/html Size: 14864 bytes Desc: not available ------------------------------ Subject: Digest Footer ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ <https://mailman.ripe.net/mailman3/lists/address-policy-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/ <https://www.ripe.net/membership/mail/mailman-3-migration/> ------------------------------ End of address-policy-wg Digest, Vol 161, Issue 11 **************************************************