Sizing IPv4 for a BEAD Build: How Many Addresses Does a Subgrant Actually Require?
BEAD has moved from planning to construction. State final proposals have been approved, subgrantees have been selected, and network builds funded by the $42.45 billion program will run through the end of the decade. The grant budgets behind those builds itemized fiber, conduit, drops, labor, electronics, make-ready, and engineering in exhaustive detail. Very few of them itemized IP addresses.
That omission is understandable (address space feels like plumbing, not plant) but it leaves network administrators at newly funded ISPs holding a question their finance teams never priced: how much IPv4 does a network passing 5,000, 20,000, or 100,000 locations actually need, and where will it come from? ARIN cannot supply a new entrant at build scale, and hasn’t been able to since its free pool depleted in September 2015. The answer will come from the transfer market, which means it belongs in the budget as a planned line item, not as an emergency purchase negotiated mid-deployment while activations wait. What follows is a practical sizing exercise: the subscriber math, the architectural fork that determines your ratio, the IPv6 offload that shrinks the translation burden, the addresses the network itself consumes, and the gap between what ARIN will give you and what your build plan requires.
Start With Locations, Then Apply the Take-Rate Curve
BEAD counts broadband serviceable locations (BSLs), which are the homes and businesses a funded network must pass. Address demand, though, follows subscribers, and subscribers are locations multiplied by take rate. Rural fiber builds commonly see take rates in the 20–30% range in the first year of service, climbing toward 40–60% or higher at maturity in footprints where the funded network is the only modern wireline option. Your milestone schedule assumes this ramp: activation targets rise year over year through the construction period and beyond.
The mistake to avoid is sizing address procurement to day-one demand. Address space acquired in fragments over several years costs more per address, arrives as disaggregated small blocks that complicate routing and aggregation, and exposes each purchase to prevailing market prices. The routing consequences of fragmentation are real, with more prefixes to announce and less to aggregate, but the internal overhead need not be: a capable IPAM/DDI platform that automates subnet tracking, assignment workflows, and DNS/DHCP synchronization makes a portfolio of disaggregated blocks operationally manageable in a way spreadsheets never will. Treat fragmentation as a BGP cost you minimize through purchasing strategy and an operations cost you automate away. Size the forecast to the mature take rate your business plan projects, or the same number your grant application promised the state, and then decide how much of that total to acquire up front versus staged. The forecast and the procurement schedule are separate decisions; the forecast comes first.
The Baseline Architecture: One Public IPv4 per Subscriber
The simplest architecture assigns each subscriber CPE a dynamically allocated public IPv4 address on its WAN interface. Demand under this model is effectively one address per active subscriber, plus overhead. A network expecting 10,000 mature subscribers needs on the order of 11,000–12,000 addresses once business services and infrastructure are counted; practically, a /18 (16,384 addresses) with comfortable headroom, or a leaner /19 plus /20 combination.
Public-per-subscriber addressing buys real operational simplicity: no translation tier to engineer, no session logging infrastructure for lawful-process response, no port-forwarding breakage generating support tickets, and clean subscriber attribution when an abuse complaint arrives. For a small operator with a lean NOC, those avoided costs are not trivial. The price is the address space itself, and at current market rates that price is calculable, which is exactly the point of this exercise.
CGNAT Changes the Ratio, Not the Requirement
Carrier-grade NAT shares a pool of public addresses across many subscribers, with inside addressing drawn from the 100.64.0.0/10 shared address space reserved for exactly this purpose (RFC 6598 — do not use RFC 1918 space here if any subscriber-side equipment might also use it). CGNAT vendors advertise consolidation ratios in the hundreds; production deployments that care about subscriber experience run far more conservatively. Residential ratios between 8:1 and 32:1 are common in practice, constrained by per-subscriber port allocations, port-block logging granularity, and the behavior of consoles, cameras, and video-conferencing clients that hold many simultaneous sessions.
Even at 16:1, CGNAT does not eliminate public IPv4 demand, it re-shapes it into three components. First, the translation pool itself: 10,000 subscribers at 16:1 requires roughly 625 pool addresses. Second, static assignments for the customers CGNAT cannot serve: business subscribers hosting services, running site-to-site VPNs, or simply demanding a static address as a condition of the sale. In rural footprints (farms with telemetry, clinics, schools, municipal offices) plan for 5–10% of the subscriber base to need static public space, often in /29 or /28 assignments that consume addresses faster than one-per-customer. Third, infrastructure, covered below. CGNAT also carries its own costs a sizing exercise should acknowledge: translation hardware or software licensing, logging storage sized to retention requirements, and the ongoing support burden of NAT-broken applications. The right comparison is never “CGNAT versus buying addresses”, it is total cost of each architecture over the compliance horizon of the grant.
Dual-Stack Is the Deployment Standard — and It Shrinks the IPv4 Bill
Everything above sizes the IPv4 side of the network, but a greenfield build in 2026 should not be an IPv4-only network with CGNAT bolted on. Dual-stack is the deployment standard for new construction: every subscriber gets native IPv6 alongside whatever IPv4 architecture you choose. The IPv6 side is effectively free, as ARIN allocates it generously and without a waiting list, and it never appears on a transfer-market invoice.
Dual-stack is not just hygiene; it changes the IPv4 arithmetic. A large share of residential traffic, such as the major content, video, social, and CDN destinations, is reachable over IPv6, and on a dual-stacked network that traffic flows natively, never touching the CGNAT tier. Fewer translated sessions per subscriber means higher defensible consolidation ratios, smaller public pools, lighter logging volumes, and smaller translation hardware. Operators who want to go further can deploy IPv6-mostly architectures, such as NAT64/DNS64 with 464XLAT on the CPE, or MAP-T, that treat IPv4 as a translation service at the network edge, reserving public IPv4 almost entirely for pools, statics, and infrastructure. None of this eliminates the IPv4 requirement — business statics, infrastructure, and the long tail of IPv4-only destinations remain, which is why the sizing exercise still matters — but running strictly IPv4-plus-CGNAT with no IPv6 offload carries a heavier, more expensive NAT burden than current deployment practice requires. If your build is dual-stacked from day one, say so in the forecast: it is what makes the aggressive end of the CGNAT ratio range defensible.
The Addresses the Network Itself Consumes
Subscriber math dominates the forecast, but the network itself needs public space that admins under deadline pressure routinely forget to reserve. Loopbacks and point-to-point links can and should live in private or IPv6 space, but several functions cannot: BGP sessions with transit providers and exchange peers, authoritative DNS, mail infrastructure if you operate it, customer-facing portals and speed-test servers (worth noting that funded networks face performance-testing obligations, and on-net test infrastructure needs stable public addressing), and the NAT pools already counted above. Reserve public space for these functions explicitly, in their own aggregates, so subscriber-pool growth never forces infrastructure renumbering. As a planning figure, infrastructure plus business statics together typically add 10–20% on top of raw subscriber demand — more at small scale, where fixed infrastructure costs don’t amortize.
Three Worked Examples
The table below applies the arithmetic to three build sizes, assuming a 50% mature take rate, a 16:1 CGNAT ratio where CGNAT is used, 5% of subscribers taking static business service, and infrastructure reserves. Treat these as starting points to adjust with your own take-rate projections and business mix, not as answers.
Three observations fall out of the table. The spread between architectures is roughly an order of magnitude at every scale, which is why the CGNAT decision has to precede the procurement decision. The CGNAT column assumes a conventional 16:1 ratio; a network dual-stacked from day one, with the bulk of high-volume destinations offloaded to native IPv6, can defensibly plan tighter. And even the CGNAT column lands well beyond what any registry will allocate to a new entrant, which brings us to the gap this exercise exists to expose.
The ARIN Gap
A new ISP organization in the ARIN region automatically qualifies for an initial /24 allocation with 256 addresses. Beyond that, ARIN issues IPv4 only through its waiting list, where the maximum an organization may qualify for is a /22 (1,024 addresses), and only organizations holding less than a /20 in aggregate are eligible to apply at all. The list is fed by intermittent reclamations, distributed quarterly, and deeply oversubscribed: the backlog has run in the hundreds of unmet requests through 2026, with waits measured in a year or more; and ARIN itself has previously told the community that a new entrant should expect to wait as long as three years. Space received from the waitlist also carries a 60-month restriction on most transfers, a condition worth reading precisely: it restricts the recipient from transferring the space onward (no market transfer out for five years; merger-and-acquisition transfers excepted), not from receiving or deploying it. Waitlist space is fully usable capacity from day one — it just isn’t a liquid asset you could later resell if the build’s needs change.
Set that against the table above. The leanest CGNAT build at the smallest scale needs a /23; the waitlist maximum, delivered on an unpredictable schedule a year or more out, is a /22. Every other cell in the table exceeds the waitlist ceiling by multiples: in the 100,000-location public-addressing case, by a factor of sixty-four. The waitlist is a legitimate supplement for a very small operator with time to wait. It is not a plan. For a BEAD subgrantee with contractual activation milestones, the transfer market is the plan, and the only real questions are structure and timing.
Buying, Leasing, and the Budget Line
The good news is that the market side of this problem is currently favorable to buyers. After peaking above $50–60 per address in late 2021, transfer prices have corrected substantially: publicly priced transactions in the first half of 2026 averaged around $20 per address, with small blocks like /24s commanding a premium near $30 and large blocks trading near or below $20. Transfer volumes are simultaneously at record highs, which means liquidity; the blocks you need exist and are findable.
Put budget numbers on the worked examples: a /20 runs very roughly $90,000–$120,000 at current prices; a /18 in the $330,000–$400,000 range; a /16 somewhere near $1.3 million. Against the total capital cost of the fiber build those addresses serve, even the /16 is a low-single-digit percentage, but it is a percentage that must be in the budget because it is not discretionary. Leasing offers a second structure: market lease rates run roughly $0.30–$0.50 per address per month, which matches spend to the take-rate ramp and avoids capital outlay in the construction-heavy early years. A hybrid is often the defensible middle path: lease to cover the first activation phases, then purchase permanent space as subscriber revenue and milestone completions de-risk the forecast, treating the lease as a bridge rather than a permanent posture. Whatever the structure, leave time for mechanics: an ARIN 8.3 transfer involves justification, officer attestation, and registry processing, so plan the acquisition weeks ahead of the activation date that depends on it, and vet any block’s routing history and blocklist reputation before closing (a cheap block that residential mail servers reject is not cheap).
Hand Finance a Forecast, Not a Surprise
The deliverable from this exercise is a one-page forecast: chosen architecture (dual-stacked, with the IPv4 side specified), projected address demand at each milestone year through take-rate maturity, the split between subscriber pools, business statics, and infrastructure, and a procurement schedule with structure (purchase, lease, or hybrid) and budget attached. Put it in front of finance before construction consumes all attention, and revisit it at each milestone against actual take rates. If this isn’t something you’ve done before, or something you need help with, reach out and talk to one of our engineers.
Address space is among the cheapest components of a funded build to secure in advance and among the most disruptive to fix late. Renumbering a live subscriber base, or discovering at activation that the pool is empty and the waitlist is a year deep, are problems with no fast solution. A defensible forecast, delivered early, makes IPv4 what it should be: a planned line item that never makes the incident log.