Worldwide operating IPv4 Broker and Internet Number Resources provider. Buy, sell, rent & lease out IPv4 and IPv6 addresses. LIR registration & management, AS/PI registration & support RIPE | ARIN | APNIC | LACNIC
 

IPv6 Stockpiling in RIPE NCC: Problem, Impact of Solutions on Transfers, and Ongoing Discussions

1. Origins of the Problem

In the mid-2010s, the RIPE community adjusted IPv6 policies to encourage adoption by making large allocations easier to obtain. Notably, a 2018 policy update clarified that each Local Internet Registry (LIR) account – not just each organization – could get an IPv6 allocation of up to /29 without additional justification. This allowed organizations to create multiple LIR accounts under one corporate umbrella, with each account eligible for a separate /29 block. Some RIPE members began exploiting this by opening multiple LIR accounts per company to stockpile /29 IPv6 allocations, then later merging those accounts or transferring the address blocks to consolidate resources. In practice, an organization could quickly accumulate many /29s – for example, by 2020 one member had merged enough LIRs to amass 91 separate IPv6 allocations (equivalent to 728 /32s)

At the same time, IPv6 transfer markets appeared. Since 2015, RIPE policy has allowed IPv6 allocations to be transferred between holders (much like IPv4 transfers) without requiring the recipient to justify need up to a /29. The original intent was to accommodate cases like network acquisitions or to help companies with multiple discrete networks avoid renumbering. However, this created a loophole: a member could request a /29 on one LIR account (no questions asked), then immediately transfer that block to another party or to a central account. Over time, some members systematically collected IPv6 blocks through these means – either requesting many /29s via extra LIRs or buying them via transfers – effectively stockpiling large IPv6 blocks “by the book” but against the spirit of the policy.

RIPE staff began sounding the alarm as these practices accelerated. Marco Schmidt (RIPE NCC’s Registration Services Manager) likened the situation to a Trojan horse: everything was happening within the rules, yet it threatened to undermine IPv6 policy goals. In a May 2024 RIPE Labs article, he revealed the extent of stockpiling: over 6,000 IPv6 allocations had changed holdership via policy transfers – fully 25% of all IPv6 allocations ever made by RIPE – and a handful of members held dozens or even hundreds of separate IPv6 prefixes. Far from the rare edge-cases originally envisioned, IPv6 stockpiling had become a growing trend.

2. Discussions in the RIPE Community

The RIPE community began actively debating IPv6 stockpiling once evidence of the trend emerged. At RIPE 82 and other forums, Marco Schmidt presented data on how IPv6 blocks were being amassed, prompting community discussion about policy intent. On the Address Policy Working Group mailing list, RIPE NCC’s analyses in late 2021 already showed alarming figures: almost 700 IPv6 allocations had been transferred in 2021 alone, and more than 3,900 transfers had occurred since 2015. They noted that 60% of all IPv6 allocations were by then held as part of multiple prefix holdings (i.e. one org controlling several blocks), and in the months prior, 75% of new IPv6 allocations were going to organizations that already had at least one allocation.. As of 2021, over 1,500 members held more than one IPv6 allocation (exceeding a /29 in aggregate), with nearly 100 members holding over 10 each. This was strong evidence that many were leveraging the “one /29 per LIR” rule to gather extra space.

Community concerns centered on both policy fairness and operational impact. Many felt these behaviors violated the intent of IPv6 policies that expected one reasonably sized block per org for the long term. If a few actors accumulated excess IPv6 space without demonstrating real need, it could undermine the principle of conservation (even if IPv6’s address pool is enormous). RIPE community pointed out several risks: the lack of utilization oversight meant stockpiled addresses might sit unused (or be subleased to others) contrary to policy goals. It created a secondary market for IPv6, including rental of large blocks, which could lead to abusive or malicious use (e.g. spammers leasing “clean” IPv6 space), harming the reputation of those addresses. Operationally, the surge in transfers put a heavy workload on the RIPE NCC registry team and introduced registration inconsistencies (if chunks of allocations were reassigned to third parties without clear documentation). It rendered the policy’s requirements for large allocations moot – why go through justification to get a /27, if you could just collect multiple /29s via transfers?

On the mailing list, community members and leaders discussed possible remedies. Two broad approaches emerged: liberalize the policy or tighten it. One camp argued that if so many needed more than a /29, perhaps the policy should simply allow a bigger initial allocation (on “nibble” boundaries like /28) without hassle. This would let networks get sufficient space in one block and reduce the incentive to game the system with multiple /29s. Others countered that the trend was abuse of policy intent, not legitimate need – and that RIPE should enforce the original spirit by preventing easy accumulation. That could mean giving the RIPE NCC a stronger mandate to require justification or even barring multiple allocations per company. An interesting point raised was the role of multiple LIR memberships: since opening extra LIR accounts had mainly been a strategy to get additional IPv4 /22s during IPv4 run-out, some asked whether “multiple LIRs” should continue to be allowed so freely now that IPv4 is exhausted . In essence, should one company be limited to one IPv6 allocation? This idea – reversing the 2018 change – gained some support as a clean solution to stockpiling, though it would require careful policy development (and handling existing cases). As Jordi Palet put it, once there are no IPv4 advantages to multiple LIRs, “is there any real business [need] to allow multiple LIRs without a stronger justification? Because that will also resolve this problem…”

Throughout 2022–2023, these discussions continued on mailing lists and RIPE meeting sessions. By RIPE 88 (May 2024), there was broad agreement that action was needed to curb IPv6 stockpiling. The community coalesced around a two-pronged response: enforce the existing rules more strictly (to close loopholes immediately) and consider policy changes (to address underlying incentives).

3. Policy Changes and Decisions

Enforcement of existing policy came first. In June 2024, the RIPE NCC announced an “Updated Approach to IPv6 Transfer Requests,” effectively closing the free-for-all on IPv6 block transfers. From 17 June 2024 onward, any IPv6 allocation policy transfer would require the recipient LIR to justify their need if they already held an IPv6 allocation. This change targeted the stockpiling practice directly – no longer could a member with one /29 simply receive another /29 (from a transfer) with zero questions asked. It’s important to note this does not prevent transfers outright; it just enforces the IPv6 subsequent allocation criteria during the transfer process. Transfers due to mergers or acquisitions (M&A), however, remain exempt from such evaluation – if an IPv6 block moves due to a corporate merger, RIPE NCC handles it as an administrative change, not a policy transfer.

In parallel, the community began considering policy proposal “2024-02”, which aims to change the IPv6 allocation policy itself. This proposal, introduced in late 2024, suggests increasing the default initial IPv6 allocation from /29 to /28 (on a nibble boundary) without requiring any additional justification. The rationale is that many networks might legitimately need a bit more space (for example, to simplify reverse DNS or to accommodate growth) and that a /28 boundary makes administration easier (since /28 is 16×/32s, allowing clean hex boundaries in addresses). By granting up to /28 from the start, the policy would “foster IPv6 adoption” by reducing the overhead of justifications in common cases. It would also remove the incentive to create multiple accounts or do transfers just to get an extra nibble of space. Importantly, the 2024-02 proposal (version 2.0) includes safeguards influenced by the stockpiling issue: it allows only one such extension (to /28) per organization and only if the allocation was originally issued as a single prefix. In other words, an org can’t keep transfering new /29s to get endless /28s – they can get one /28 (if needed) and that’s it, which “limits some of the potential adverse effects of stockpiling.”

Arguments for and against this policy change have been debated. Supporters note that a /28 on nibble boundaries can greatly ease network operations (especially DNS delegation) and that the RIPE NCC already reserves a /26 for each /29 issued. Therefore, allowing a /28 by default wouldn’t significantly deplete the IPv6 pool or routing table – in fact, 91% of existing allocations could be extended to /28 from reserved space, according to RIPE NCC stats. It could actually reduce routing table growth by keeping allocations contiguous instead of scattered via transfers. On the other hand, opponents worry that doubling the default allocation goes against the conservation mindset and could facilitate even larger hoarding. A /28 could be split into 16 separate /32s for resale, whereas a /29 can be split into 8 – potentially encouraging a “bigger pie” of addresses to partition and transfer. The proposal counters this by pointing out that any allocations resulting from partial transfers can no longer be extended – you lose the one-time /28 extension if you chop up your block. This disincentivizes the practice of splitting and selling sub-blocks, since doing so forfeits the ability to ever grow that allocation via the easy path. As of early 2025, proposal 2024-02 is still under discussion, with community input divided between those favoring a proactive size increase vs. those favoring tighter controls per org.

Another policy idea, as noted, is to limit allocations per company rather than per LIR. While no formal proposal on this has been published yet, the topic is often raised in discussions. It would mean reverting the 2018 change and enforcing that an organization (legal entity) can only get one “initial” IPv6 allocation without additional need justification, no matter how many LIR accounts it holds. Proponents say this would directly close the loophole that enabled stockpiling – essentially treating attempts to game multiple LIRs as one request. This approach was hinted at by members like Jordi Palet Martínez in the Address Policy WG, suggesting that after IPv4 exhaustion there’s little legitimate reason for an entity to open extra LIR accounts except to manipulate resource distribution . However, implementing this would require mechanisms for the NCC to detect and cross-check LIRs belonging to the same company, which can be complex (companies could be related via holding firms, etc.). The idea remains part of the “where do we go from here?” conversation on building a more stable long-term framework that can’t be as easily gamed. RIPE NCC’s executives have even called for a broader strategy review of the membership and registry system to ensure sustainability and address such loopholes holistically (e.g. tying membership structure and charging schemes to discourage creating many dummy accounts) (IPv6 Stockpiling: A Trojan Horse in Our Midst? | RIPE Labs).

4. Analysis of IPv6 Transfers Before and After Policy Change

To quantify the impact of the Updated Approach to IPv6 Transfer Requests, we analyzed RIPE’s published IPv6 transfer statistics. The figures below show the number of IPv6 allocation transfers over time from 2019 through December 2024, broken down into four categories: “Policy” transfers of blocks smaller than /29, Policy transfers of blocks equal or larger than /29, M&A transfers smaller than /29, and M&A transfers equal or larger than /29. “Policy transfers” are voluntary market transfers between LIRs under RIPE policy, whereas “M&A” transfers are those due to business mergers or acquisitions (as indicated in the RIPE stats). We further distinguish transfers involving a normal-sized block ( smaller than /29) versus an extra-large block (> /29).

IPv6 allocation transfers in the RIPE region (2019–2024).

“Policy Transfers < /29” represents market transfers of /30 or smaller prefixes, mostly /32s, and “Policy Transfers ≥/29” represents transfers of /29 or larger blocks. Similarly, “M&A” categories represent transfers due to mergers and acquisitions. The data illustrates the rapid growth of policy transfers of /29 IPv6 subnets and larger from 2019 through 2023, followed by a sharp drop-off after the mid-2024. This coincides exactly with RIPE’s June 2024 decision to require needs-based approval for IPv6 transfers. M&A-related transfers slightly increased from July 2024. Given the new requirement to justify /29 needs, M&A appears to be for some organisations the viable solution for accumulating multiple /29s under a single LIR account. The increase in Policy and M&A transfers each December is likely linked to the RIPE annual membership fees, prompting LIR holders to transfer resources and close their accounts before the next year’s billing cycle applies. Policy transfers dropped to 2018 levels by the end of 2024, suggesting that the new enforcement effectively halted the previous transfer market rush. In contrast, M&A transfers (which were not subject to the new requirement) did not show a particular drop – they continue at the low baseline rate.

It’s worth noting that if the community adopts proposal 2024-02 (allowing /28 by default), we may see a one-time uptick in allocation sizes but not necessarily in transfer counts. In fact, the goal of that proposal is to reduce the need for transfers by giving networks more headroom initially. Our analysis suggests that the combination of enforcement and potential policy tweaks will likely keep IPv6 transfers low in the near future. There may be a backlog of justified cases (e.g. networks that truly needed a second prefix) now going through approval, but those are inherently limited in number compared to the speculative transfer activity we saw before.

5. Conclusion

IPv6 stockpiling in the RIPE region was enabled by well-intentioned policy choices that prioritized easy IPv6 deployment over strict control. Allowing each LIR account an IPv6 /29 (with no substantial justification) and permitting unrestricted transfers created a scenario where a small number of actors could accumulate outsized IPv6 holdings completely within the rules. The RIPE NCC’s data and our analysis show that from 2019–2023, thousands of IPv6 /32–/29 blocks were obtained and consolidated by a few members, contributing to over 25% of all RIPE IPv6 allocations changing hands. This raised valid concerns about policy loopholes, potential misuse of address space, and fairness to those who played by the original intent of one-organization-one-allocation.

RIPE’s response in 2024 was decisive. By re-imposing needs-based evaluation for IPv6 transfers, the NCC closed the main loophole fueling stockpiling. As our transfer trends analysis indicates, this effectively stopped the rapid accumulation of IPv6 via the transfer market – transfers dropped to near zero once organizations had to justify additional space. This move was backed by the RIPE community and can be viewed as reinforcing the principle of responsible stewardship of IPv6. It sends a clear message: just because IPv6 is abundant doesn’t mean grabbing more than you need will be ignored. In parallel, the community is updating policies to prevent such issues from recurring. The proposal to enlarge the default allocation to /28 (with one per org) is essentially a trade-off: giving networks a bit more space upfront (to dissuade creative workarounds) while closing the door on unlimited prefix accumulation. If adopted, this policy would legitimize what stockpilers claimed to need (more space for growth or segmentation) but within a controlled framework. On the other hand, if the community feels even stronger about stopping any stockpilling attempt, we may see moves to explicitly cap allocations at one per organization – though enforcing that could be challenging.

The IPv6 stockpiling episode in RIPE highlighted the need to periodically recalibrate policy as real-world behavior unfolds. What started as a generous policy to encourage IPv6 uptake was later utilized by a small group of members to accumulate resources beyond what was initially expected. The RIPE community, through its bottom-up process, identified the problem and acted – first by tightening enforcement, and now by debating policy adjustments. Going forward, we can expect RIPE to monitor IPv6 allocations and transfers closely. Additionally, as other RIR communities watch RIPE’s experience, they could adopt similar measures – this is important for global consistency, so that stockpiling doesn’t just shift to another region.

In the big picture, IPv6 itself has plenty of address space, but policy still matters to ensure fairness and good stewardship. RIPE’s handling of IPv6 stockpiling shows the maturity of the community in governing its resources: when a Trojan horse was spotted within the gates, the community did not hesitate to address it. By closing policy gaps and refining the rules, RIPE is working to maintain an IPv6 environment where addresses are readily available for those who need them – and only for those who need them. This balances IPv6’s “abundance” with prudent management, helping to secure a stable future for the IPv6 ecosystem in the RIPE region.

6. References and Data Sources

Author: Anastasia Kleiman.

GermanRussiaFrenchLithuaniaEnglish
Shopping cart0
There are no products in the cart!
Continue shopping
0