Wait. IPv6 stockpiling is a thing

In a detailed and well-articulated post, Marco Schmidt and Rene Wilhelm discuss the possibly contentious issues in potential IPv6 stockpiling.

Their main observation is that a small group of RIPE members has been accumulating large holdings in the IPv6 address space through the acquisition of otherwise distinct delegations - ones that can be seen to be involved in IPv6 transfers. As a result, around 25% of all IPv6 allocations have been consolidated, involving the unification of over 6,000 distinct delegations.

It seems unclear why a quarter of all transactions have been directed to create such large holdings when under existing policy it should be possible to justify more than an adequate supply of addresses.

As the blog post notes, this may not seem a significant concern set against total IPv6 address space. Less than 0.004% of global unicast IPv6 space has been allocated to the RIPE NCC specifically, and all Regional Internet Registries (RIRs) taken together have received only around 1.4% of the IANA reserve. So there is no direct threat to the available pool of IPv6 as a result of this activity.

However, the potential procedural implications of this situation are significant. These reserves are sufficient to allow another agency to engage in sub-leasing IPv6 addresses, creating more complex projections for resource consumption, policy development, and membership planning. There may be national strategic reasons to pursue this, reflecting the governance complexities in the RIPE region, and it could encourage similar behaviour in other RIR communities.

Rather than speculate here on what's going on, I encourage you to read and engage directly on the RIPE Labs blog. There's potential for wider discussion in the APNIC-talk and policy lists, if it turns out that there are implications for addressing policy processes.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.