How many subscribers can share one public IPv4? The CGNAT port-block maths

Every operator who runs out of IPv4 asks the same question: how many subscribers can I put behind one public address? The port-block maths lets you calculate a sharing ratio and size the CGNAT pool instead of guessing.

The budget: ports, not addresses

A CGNAT (carrier-grade NAT) shares one public IPv4 across many subscribers by giving each subscriber a slice of that address's TCP and UDP port space. A public IPv4 has 65,536 ports per protocol. In practice the well-known range (0–1023) is never allocated outbound, and most deployments hold back a little more, so call it roughly 64,000 usable ports per protocol per public address.

Each subscriber needs enough ports to cover the connections their household opens at once. A phone, a few browsers, a smart-TV app and a game console together hold hundreds of simultaneous flows without anyone noticing. Give each subscriber a port block, a contiguous range reserved for them, and calculate the sharing ratio:

subscribers per public IP  ≈  usable ports (~64,000)  ÷  block size

So a single /28 of public space (16 addresses) carries somewhere between about 240 and 2,000 subscribers depending purely on the block size you choose. The block size sets the sharing ratio when you plan CGNAT.

The trade-off you are actually making

Bigger blocks mean fewer port-exhaustion events: a power user running a busy torrent client or a CGNAT-hostile application has room before they hit the ceiling. But bigger blocks mean fewer subscribers per address, so you burn through public space faster. Smaller blocks pack more subscribers onto each IPv4 but raise the chance that a heavy household runs out of ports and sees connections fail.

Start conservative (a 2,048-port block is a sane residential default), watch real occupancy, and tighten only if the data says you can.

Deterministic blocks, so you can answer questions later

How the block is allocated matters as much as its size. Netavo BNG uses deterministic port-block allocation: when a subscriber's session comes up, the CGN hands it a contiguous block from the group's public pool. The public address and that first port block are stamped onto the subscriber's RADIUS accounting record (they appear on the Accounting-Start, in 1024-1535 form), and any further blocks a heavy user needs are recorded as allocation events. So the mapping from a public address and port range back to a subscriber comes from the accounting record plus the allocation history. That is a tiny fraction of what a per-flow NAT would log to answer the same question. (See the companion note on CGNAT logging.)

The public space is declared per group:

"cgn": {
  "enabled": true,
  "ipGroups": [
    { "name": "fttx-south-cgn",
      "description": "Public addresses for the fttx-south subscribers",
      "outsideVrf": "",
      "publicSubnets": ["45.84.201.0/28"] }
  ]
}

Subscribers in that group are mapped onto the publicSubnets, each taking a block. The binding is stamped onto the RADIUS accounting record (the public IP and the port block appear on the Accounting-Start), so your usage and compliance records carry it without a separate log pipeline.

Keeping the ratio healthy

A few mechanics keep real-world density close to the theoretical maximum:

• Stickiness. A returning subscriber tends to get the same public address and block, which keeps mappings stable for anything that pins to an address and avoids churn in your records.
• Reclaiming empty blocks. When a subscriber's upper port blocks fall idle, the allocator can hand them back so the public pool is not fragmented by peaks that have passed.
• Occupancy visibility. You can see how full each binding's blocks are, so the decision to shrink the block size is driven by measured headroom rather than a guess.

Honest edges

• The ratio depends on your port-block policy. Anyone quoting "N subscribers per IP" without stating the block size is hiding the assumption. Decide the block size first; the ratio follows.
• Some applications are port-hungry. A minority of users and a minority of apps open many simultaneous flows. Size for your 95th-percentile household, monitor occupancy, and keep a small escape hatch for the outliers.
• Plan for IPv6 alongside CGNAT. CGNAT buys you time and conserves IPv4; it is not a substitute for deploying IPv6, which removes the whole problem for traffic that can use it. Run both.

Work it out on your own numbers

The free evaluation build is the full production build with CGN enabled, licensed for up to 50 concurrent subscribers. Stand it up, point a block of public space at it, and watch real port-block occupancy as test subscribers generate load before you commit to a ratio in production. Start at netavobng.com/evaluation; the CGN design and configuration reference is in the manual.