Summary

  • In May 2024, RIPE NCC registration-services manager Marco Schmidt reported that more than 6,000 IPv6 allocations had changed holder through policy transfers, roughly a quarter of all IPv6 allocations RIPE NCC had ever distributed. Fourteen members holding more than 50 allocations each controlled nearly 9% of the IPv6 space allocated by RIPE NCC.
  • On 17 June he announced that a recipient already holding an IPv6 allocation would have to document a need for another when seeking a new policy transfer. A deployed network on the transferred range could satisfy that need; mergers and acquisitions followed separate procedures.

The abundance had a filing cabinet

Schmidt's May account starts with an awkward administrative fact. IPv6 is vast, yet collecting allocations can still be a repetitive transaction. Among the ten members with the most IPv6 allocations, seven had just one LIR account and had built their holdings through transfers. The fourteen members above 50 allocations together held almost 9% of the IPv6 space allocated by RIPE NCC. That denominator matters: he was describing concentration inside one registry's allocated pool, not a shortage of global IPv6 addresses.

The file handling was less abstract. Schmidt estimated that 300 initial allocation requests would consume 100–150 staff hours at 20–30 minutes apiece. Processing 300 subsequent transfers would add about 300 hours at 50–60 minutes each. The example yields roughly 400–450 hours of registry work before a single operator's network use has been established. It was an illustrative accumulation, not a claim that every large holder had followed exactly that route. RIPE NCC members fund the staff doing the work.

The old design supplied two paths with different questions. Since 2018, an LIR account could receive a /29 IPv6 allocation with minimal justification. A member asking RIPE NCC for further space normally had to explain its deployment. Transfers made it possible to accumulate additional allocations through other holders without the same scrutiny at the receiving end. Schmidt said the observed conduct was consistent with the policies then in force. He also acknowledged that routing announcements and ROAs could not prove whether an address range served end users. The record showed accumulation; it did not reveal every buyer's purpose.

On 17 June 2024, after the RIPE 88 address-policy discussion, Schmidt announced a changed application of the transfer requirements. For new policy-transfer requests submitted from that day, a recipient that already held an IPv6 allocation had to document why it needed another. Use of the existing allocation or a need for a new one could supply the explanation; a successfully deployed network on the range being transferred could count. Changes of holder caused by a merger or acquisition went through their own procedures. In his 19 June clarification, he drew the practical line: support transfers of live networks, and assess unused transferred blocks as new allocation requests.

That decision put a question at the desk where the address record changes hands. RIPE NCC's institutional notice confirmed the approach. The public sources establish the announcement and its scope; they do not supply a later count of rejected transfers or a measured reduction in stockpiling.