Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status
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
Hi Clara, all, In my opinion, it will make sense that if you received the resources as legacy and you want to keep that status, you only get the basic set of services, just to keep the registry updated, unless you are a member and pay for the “total set of services”. I know this is a different point but I think it is related and should be mention as well. APNIC resolved that and also a policy proposal that reached consensus allows those recourses to be reclaimed if there is no response from the holder. The ability to transfer should not be part of the “basic” set of services, so clearly, if a legacy holder want to transfer, need to lose the legacy status for those resources, and following the same rationale, members that have signed a contract (for example they need IPv6 or ASN), they should have lost the legacy status of other resources. Regards, Jordi @jordipalet
El 27 oct 2025, a las 17:12, Wade, Clara via address-policy-wg <address-policy-wg@ripe.net> escribió:
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:
“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. “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:
RIPE registration services fees. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 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 ----- To unsubscribe from this mailing list or change your subscription options, please visit: 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/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Hi Clara and Peter, I think this is an excellent idea. We need more equality between our integers in my opinion, and while I'm OK with an exemption status for the original legacy holders (after all, they didn't necessarily choose to set up the RIR system and all it entails), I don't think that exemption should be maintained once that space has touched the RIR system (and has incurred cost) by means of a resource transfer. Kind regards Remco van Mook
On 27 Oct 2025, at 17:12, Wade, Clara via address-policy-wg <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:
“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. “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:
RIPE registration services fees. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 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 ----- To unsubscribe from this mailing list or change your subscription options, please visit: 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/
Hi Clara and Peter, I agree with Remco. Once legacy space relies on RIPE DB resources or adds to the RIPE NCC’s workload, it’s only fair that there’s a contractual relationship and the corresponding NCC fees apply. Regards, Rinse On 10/27/2025 11:25 PM, Remco van Mook wrote:
Hi Clara and Peter,
I think this is an excellent idea. We need more equality between our integers in my opinion, and while I'm OK with an exemption status for the original legacy holders (after all, they didn't necessarily choose to set up the RIR system and all it entails), I don't think that exemption should be maintained once that space has touched the RIR system (and has incurred cost) by means of a resource transfer.
Kind regards
Remco van Mook
On 27 Oct 2025, at 17:12, Wade, Clara via address-policy-wg <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 ----- To unsubscribe from this mailing list or change your subscription options, please visit: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/
----- To unsubscribe from this mailing list or change your subscription options, please visit: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/
Hi Clara and Peter, Thank you for a quick reminder and another opprotunity to have a look at the Charging Scheme Task Force Final Report. It's only now I've realized the time cost differences in resource transfer scenarios, i.e. 75 minutes to process each intra-RIR transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six hours for a legacy transfer between parties with contractual relationships with the RIPE NCC, seven hours for a legacy transfer between parties without contractual relationships. Do 75 minutes for processing an intra-RIR transfer also apply to (cover) PI address resources? It's a fraction of time for what it takes to transfer a legacy resouce even if both parties are already in a contractual relationship with the RIPE NCC. Also seven vs six hours for a legacy transfer between parties without vs with contractual relationship stays away from an inter-RIR or M&A transfer. Is the extra time required for due diligence wrt transfered (legacy) resources? Or other aspects apply to legacy resources that we have to count in. Thank you for your patience and comments. Kind regards, Martin On Mon, Oct 27, 2025 at 04:12:30PM +0000, Wade, Clara via address-policy-wg 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
----- To unsubscribe from this mailing list or change your subscription options, please visit: 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/
participants (5)
-
jordi.palet＠consulintel.es -
Martin Stanislav -
Remco van Mook -
Rinse Kloek -
Wade, Clara