Carrier-Grade NAT · intelligent port-block allocation · pressure-adaptive · keepalive-safe · RFC 7422
Infrastructure Brief · Carrier-Grade NAT

Share every public IPv4 — without dropping a single connection.

The public IPv4 you own is finite; your subscriber count is not. Carrier-Grade NAT lets one public address serve hundreds of homes by handing each a slice of ports. The catch every operator hits: ports run out, and the usual fixes make things worse — short idle timeouts kill live sessions (SSH, VPN, gaming, video calls, IoT), long ones hoard ports until the pool is exhausted and the internet "feels slow." BNGSOFT solves both at once with a port allocator that reads real pressure per subscriber, reclaims idle ports exactly when they're scarce, and is mathematically prevented from ever cutting a live connection.
0
live sessions dropped
SSH / VPN / gaming survive every reclaim
~24 s
idle-port reclaim under load
fast-lane sweep + instant empty-block release
GAP = 0
no phantom ports
allocated ports = live sessions, always
line rate
XDP data plane
translation in-kernel, per packet
A CGNAT that reclaims ports by dropping the customer's own live connection hasn't saved the pool — it has created a support ticket. Reclaim the idle, protect the live.

What Carrier-Grade NAT does — and why the allocator is the whole game

There aren't enough public IPv4 addresses left for one-per-subscriber, and buying more is expensive and getting more so. Carrier-Grade NAT (CGNAT / NAT444) lets an operator put many subscribers behind a single public IPv4. Each subscriber keeps a private address on their side; on the way out, the BNG rewrites it to the shared public IP plus a port from that subscriber's own block. Replies come back to that public IP:port and are translated straight back to the right home.

Subscribers (private) Home A100.64.0.10 Home B100.64.0.11 Home C100.64.0.12 … hundreds more example RFC 6598 space BNGSOFT CGNAT rewrite src IP + port A → block 1024–1151 B → block 1152–1279 C → block 1280–1407 1 shared public IPv4 203.0.113.7 65,536 ports → many blocks Internet reply → IP:port
One public address, many homes. Each subscriber owns a distinct port-block; the return traffic maps the public IP:port straight back to the right home. The allocator that hands out — and takes back — those blocks decides whether the pool ever runs dry.
Why the block, not the flow? Logging every single connection for lawful-intercept would generate an unmanageable torrent of records. Allocating a contiguous block of ports per subscriber (RFC 7422) means one compact log line covers thousands of connections — deterministic, auditable, and a fraction of the storage.

The hard problem: ports are finite, and the naive fixes both fail

A public IP has ~64,000 usable ports. Hand them out in blocks and you fit hundreds of subscribers per address — if you reclaim blocks when a subscriber goes quiet. The moment reclaim is wrong, one of two failures shows up on your NOC dashboard:

Failure 1 · timeouts too long
Ports get hoarded → pool exhaustion
  • Idle connections keep their ports for hours.
  • Busy subscribers can't get a new block.
  • New connections silently fail — pages won't load, apps time out.
  • To the customer this is "the internet is slow" with nothing obviously broken.
Failure 2 · timeouts too short
Live sessions get cut mid-use
  • A quiet-but-alive SSH, VPN, game or video-call session looks "idle".
  • Its port is reclaimed — the connection dies.
  • Remote workers get kicked, downloads break, IoT devices drop off.
  • Support tickets that are near-impossible to reproduce.
The trap: a single fixed timeout can't win. Tune it long and you exhaust the pool; tune it short and you sever live connections. Real subscriber traffic needs the timeout to change with the situation — and to know the difference between "idle" and "quietly alive."

BNGSOFT's answer: a pressure-adaptive, keepalive-safe allocator intelligent

Instead of one timeout for everyone, the allocator continuously measures how close each subscriber is to running out of ports and reacts only where and when it matters. Three ideas work together:

1 · Read the pressure

Per subscriber, compare blocks in use against their ceiling → a LOW / MEDIUM / HIGH tier, recomputed live. Most subscribers sit at LOW and are left completely alone.

2 · Scale the reclaim

Idle timeouts shorten only as pressure rises — roughly full at LOW, halved at MEDIUM, one-fifth at HIGH — so ports come back exactly when the pool is tight, and never sooner.

3 · Floor every protocol

Shortening stops at a hard floor per protocol — TCP never below 120 s. A quiet SSH/VPN/game session is always above the floor, so it is never reclaimed, at any pressure.

Idle-reclaim timeout scales with real port pressure — and stops at the keepalive floor LOW pressure pool mostly free ports used timeout = full nothing reclaimed early MEDIUM pressure pool filling ports used timeout = ½ idle ports return sooner HIGH pressure near the ceiling ports used timeout = ⅕ aggressive idle reclaim Protocol floor — TCP 120 s (keepalive-safe): reclaim can approach this line but never cross it A live SSH / VPN / gaming / video-call session stays above the floor → protected at every pressure level.
Adaptive shortening is one-directional: it can only pull an idle timeout down toward the floor, never past it and never on an active flow. That single property is what makes "reclaim harder under load" safe for live connections.

Reclaim that's fast where it counts — and instant when it can be

Fast lane
Pressured subscribers swept every ~20 s
  • The full pool is walked on a slow, cheap cadence.
  • Subscribers at MEDIUM/HIGH pressure are additionally swept on a 20-second fast lane.
  • Ports free up in seconds precisely for the subscribers who need them — without spending CPU on the 99% who don't.
Event-driven release
Empty blocks return the instant they empty
  • When a block's last session closes, the block is handed back immediately — no waiting for the next sweep.
  • A verified fresh check prevents releasing a block a new connection just grabbed.
  • Net effect: allocated ports track live sessions with zero drift (GAP = 0) — no phantom or stuck ports.

Before & after — the same busy subscriber, two allocators

Fixed-timeout CGNAT
  • Idle streaming/CDN ports held for the full fixed timeout, even at peak.
  • Heavy subscriber fans out to many blocks; tail blocks hold 1–2 ports each.
  • Pool approaches exhaustion → new connections fail intermittently.
  • Shorten the timeout to cope → the customer's SSH/VPN drops.
  • Operator is stuck choosing which failure to ship.
BNGSOFT pressure-adaptive
  • At LOW pressure the same subscriber is left untouched — generous timeouts.
  • As they fill up, idle ports are reclaimed in ~24 s, freeing blocks for reuse.
  • Their live SSH/VPN/game session stays above the 120 s TCP floor — untouched.
  • Empty blocks return instantly; GAP stays 0.
  • No exhaustion, no dropped sessions — no ticket.

How it compares to what else is on the market

Framed by category rather than by vendor — where a typical box in each class lands on the four things that decide subscriber experience.

  Legacy / static CGNAT Fixed-timeout dynamic NAT Per-flow NAT appliance BNGSOFT intelligent CGNAT
Idle-port reclaim Manual / rarely reclaimed One fixed timeout for all Per-flow expiry Pressure-scaled, per subscriber, live
Live-session safety N/A (static) Breaks if tuned short OK but state-heavy Guaranteed — protocol floor, uses max-idle
Pool exhaustion under load Common (over-provisioned to hide it) Common at peak State-table blow-up risk Prevented — fast-lane + instant release
Lawful-intercept logging Per-block Varies Per-flow (heavy storage) Per-block (RFC 7422, compact)
Where translation runs CPU / kernel CPU / kernel Fixed ASIC (rigid) XDP line-rate on commodity servers
Adapts to real traffic No No Partly Yes — reads pressure, reacts live
Reading this table fairly: categories generalise — individual products vary, and a well-provisioned box in any class can look fine until it's genuinely under load. The distinction that matters is behaviour at the edge of the pool: what happens to a busy subscriber's new connections, and to a quiet-but-alive session, when ports get scarce. That is exactly where the adaptive allocator is designed to win.

What it means for you — and for your subscribers

For the operator
  • More subscribers per public IPv4 — safe, high pool utilisation instead of over-provisioning to avoid exhaustion.
  • Fewer "internet is slow" tickets — port exhaustion, a common invisible cause, is engineered out.
  • Fewer "it randomly disconnects" tickets — live sessions are protected by design.
  • Audit-ready — compact RFC 7422 port-block records for lawful intercept.
  • Runs on commodity hardware — line-rate XDP, no proprietary ASIC lock-in.
  • Fully tunable — pressure tiers, floors and cadence are operator-configurable; the intelligent allocator can be dialled or turned off.
For the end-user
  • Pages load and apps connect — even at peak hour on a busy shared IP.
  • Remote work stays connected — SSH and VPN don't drop mid-session.
  • Gaming and video calls hold — quiet moments don't get mistaken for "idle".
  • IoT and smart-home devices stay online — long-lived keepalives survive.
  • It just works — the sharing is invisible, which is the whole point.
The one-line version: BNGSOFT reclaims idle ports harder exactly when the pool is under pressure, and is mathematically prevented from ever reclaiming a live one — so you can pack more subscribers onto every public IPv4 while the network feels like everyone has their own address.

Pack the pool. Protect the connection.

BNGSOFT Carrier-Grade NAT gives you pressure-adaptive, keepalive-safe port-block allocation: high pool utilisation without exhaustion, and not one dropped live session — all at line rate in the data plane, on commodity servers, with RFC 7422 logging built in.

Ask for a walkthrough of the allocator behaviour and how it sizes to your subscriber base — sales@bngsoft.com.

BNGSOFT · Carrier-Grade NAT · intelligent port-block allocation · keepalive-safe · RFC 7422
sales@bngsoft.com · bngsoft.com
How to read the figures (honest framing). "GAP = 0", "~24 s reclaim", the "TCP 120 s floor" and "0 live sessions dropped" describe the behaviour of the BNGSOFT intelligent allocator as validated on a running BNG: under induced port pressure, idle ports were reclaimed within roughly twenty-plus seconds while a live keepalive session held open by the same subscriber stayed connected throughout, and allocated ports tracked live sessions with no drift. Absolute reclaim time, the number of subscribers per public IPv4, and pool headroom depend on hardware, NIC, the configured block size, per-protocol floors, sweep cadence and real traffic mix, and are indicative — validate per deployment. Pressure tiers, protocol floors and the fast-lane interval are operator-tunable, and the adaptive allocator is configurable and can be disabled. Port ranges and addresses shown in diagrams are illustrative examples (RFC 6598 / RFC 5737 documentation space). This brief describes BNGSOFT BNG data-plane behaviour; internal component names and deployment details are omitted by design.