Summary

  • ARIN's current policy manual reserves a contiguous IPv4 /10 to facilitate IPv6 deployment. A qualifying applicant normally receives a /24 for an immediate IPv6 deployment need, such as dual-stack DNS or protocol translation.
  • Sections 8.3 and 8.4 exclude address resources from reserved pools, including this §4.10 pool, from specified-recipient transfers within ARIN's region and between RIRs. An address issued for this purpose cannot simply be turned into market transfer inventory.
  • Repeat access is conditional: earlier §4.10 grants must still meet the purpose test and reach at least 80% use; the ordinary six-month spacing has a discrete-network exception. A reserved grant also leaves the applicant's IPv4 Waiting List eligibility intact.

IPv4 exhaustion did not end every new IPv4 allocation at ARIN. It made the remaining routes much more specific. The Number Resource Policy Manual sets aside a contiguous /10 from ARIN's last IANA /8 for a peculiar job: helping networks deploy IPv6. A small IPv4 foothold can support a dual-stack DNS server or a translation device that lets old and new networks speak during the transition. ARIN says the need must be immediate and its staff will judge the justification. The normal grant is a /24. The premise is concrete: spend a little of a scarce old resource to get the new resource into operation.

Then comes the price of that purpose. In the same policy manual, §8.3 for transfers to specified recipients in ARIN's region and §8.4 for inter-RIR transfers both exclude addresses from reserved pools. They name §§4.4 and 4.10. ARIN's IPv4 request guide repeats the restriction in plain language: resources from those pools are ineligible for specified-recipient transfer. A recipient can build its IPv6 bridge on the special IPv4 block. It cannot later put that reserved block through the usual named-buyer transfer channel. This is a constraint on a defined transfer route, not a claim about every possible change of organization under the policy manual.

The rule puts a fence around an otherwise tempting arbitrage. ARIN's ordinary IPv4 free pool ran out in September 2015. Its addressing options now point applicants toward a waiting list, transfers from existing holders, and reserved pools for special needs. A block from the IPv6 deployment reserve might look like one more unit of scarce IPv4 on a balance sheet. The policy gives it a narrower job. If ARIN handed out reserved /24s and allowed them to flow directly into specified-recipient sales, a queue built for immediate IPv6 deployment could become another source of commercial supply. The prohibition closes that exit. No invented price estimate is needed to see the incentive: the same addresses would have different market possibilities depending on the conditions under which ARIN issued them.

The entry test is also tighter than “we plan to use IPv6.” Section 4.10 requires an immediate deployment need. ARIN lists key dual-stack DNS servers and NAT-PT or NAT464 translators as examples. It says applicants must show that no other allocations or assignments will satisfy the need. Staff retain discretion when judging the explanation. That arrangement gives a project team a practical homework assignment: identify the exact service that needs IPv4 during the IPv6 build, the existing space already available to it, and why that space cannot do the job. A general statement of enthusiasm for IPv6 is a poor substitute for a network design.

A second request is not a simple refill. Previous §4.10 allocations or assignments must continue to serve the same justified purpose, and the applicant must have used at least 80% of them to seek more. The default spacing is six months after a prior §4.10 grant. The policy makes a specific exception for a discrete network that has received no §4.10 resource in that six-month period. For multiple discrete networks, the aggregate grant cannot exceed a /21 equivalent in any six months. These conditions turn the special reserve into a sequence of operational tests, rather than a warehouse of cheap future options. An applicant can show a deployment, use the block, and return with evidence. It cannot acquire a row of idle /24s merely by repeating a story about eventual transition.

The Waiting List follows a separate ledger. ARIN's request guide says a reserved-pool allocation does not remove an existing Waiting List request or prevent a new one. A network can need a purpose-bound /24 to make IPv6 work while still seeking ordinary IPv4 capacity through the list. That distinction matters for planning: the bridge grant solves a specific deployment bottleneck, while the Waiting List addresses a different unmet request. It also prevents an applicant from treating the special pool as a clever way to skip the wait and then sell the result. ARIN has separated the access paths and their consequences in the policy text.

At the transfer desk, the distinction is equally visible. A prospective buyer should ask how a block was issued before pricing it as transferable inventory. A seller should check the original grant and the applicable policy section before presenting the block to a named recipient. A registry operator should be able to point to the reserved-pool designation in the resource's provenance, rather than discovering it after the parties have agreed terms. Section 8 is an admission rule for a transfer request, not a clause hidden in the seller's marketing brochure. The moment of discovery changes who bears wasted legal and planning work.

ARIN's public policy pages do not identify a particular §4.10 recipient trying to sell a block; a dated transfer request and registry decision would establish that case. The published rule already settles the treatment of a reserved block in the specified-recipient channel.