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
<[email protected]> 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/
-----
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/
