Summary

  • ARIN’s current waiting-list rule fills each IPv4 request with one contiguous block. Smaller noncontiguous blocks cannot be stacked for the same recipient. At ARIN 58, John Curran asked whether that restriction still earns its keep.
  • He also asked whether ARIN should keep issuing blocks larger than /24 when that choice serves fewer organizations. The meeting posed questions to the policy community; no change was announced in the recap.

Imagine an address cupboard with three small boxes and a request for one bigger box. The cupboard is not empty, but the rule says the pieces cannot be taped together. That is the awkward geometry John Curran brought to ARIN 58. He was speaking in the policy implementation and experience discussion, where registry staff expose the places a clean sentence in the rulebook meets an untidy inventory.

The IPv4 Waiting List guide explains the mechanics. A qualified organization states the smallest block it will accept. Requests are ordered by approval date, but fulfillment depends on the size of each available block. Returned addresses often come from revocations for nonpayment. A member can have one request on the list, and the maximum size it can qualify for at one time is a /22. The current single-contiguous-block rule means several smaller returns cannot jointly satisfy one request, even if their address counts add up.

Curran’s first question was whether the single-block restriction still makes sense. His second sharpened the trade: does aggregation still need to govern how the list is served? His third asked whether issuing blocks larger than /24 remains necessary when it means fewer organizations receive space. A /24 contains 256 IPv4 addresses. Bigger blocks help a recipient obtain a simpler, larger range; smaller awards can put scarce returned space in more hands. Neither outcome is free. Several separate blocks mean more prefixes and more administration for recipients and the wider routing system.

One larger award leaves other approved applicants waiting. Those consequences are the decision the community has to weigh, not numbers ARIN claimed to have measured at that session.

The fact that Curran posed the choice matters. ARIN staff can administer the list under the existing policy; they cannot change its allocation logic by finding a cleverer way to pack boxes. The discussion invites participants to decide which constraint still protects the system and which merely strands usable fragments. Curran did not offer a magic new pool of IPv4. He put the shape of the remaining pool in front of the people who write the rule.

Scarcity can make a policy feel like a locked cupboard. The useful question at ARIN 58 was who holds the key to changing its shelves. Curran handed that key back to the community, along with a rather inconvenient pile of small boxes.