Carrier-Grade NAT is a solved problem in principle and a frequently botched one in practice. The technology itself is straightforward: translate subscriber private addresses to public addresses so many subscribers share a small public IP pool. The design decisions around it, specifically the addressing architecture, the logging approach, and how the CGNAT function scales as subscriber count grows, determine whether the deployment works cleanly under load and satisfies regulatory requirements, or creates operational problems that compound over time.

Addressing Architecture

Three address spaces must be designed before any CGNAT configuration is written, and they must not overlap: subscriber-facing private space, CGNAT public pool, and management network.

Subscriber-facing private space should use RFC 6598, the 100.64.0.0/10 range explicitly reserved for CGNAT service provider use by IANA. Using RFC 1918 space for subscribers instead creates a well-known failure mode: subscribers who use 192.168.x.x or 10.x.x.x internally for their own home networks end up with overlapping address space between their private network and the ISP's subscriber addressing, causing routing failures for specific destinations. RFC 6598 avoids this because no equipment outside of ISP infrastructure uses it as private addressing, so overlap with subscriber home networks is impossible by design.

The 100.64.0.0/10 block provides 4,194,304 addresses. Plan your subscriber address allocation within this space with growth in mind: a /16 per PoP gives 65,536 addresses per site and supports CGNAT logging correlation at the PoP level, which simplifies log queries when responding to abuse complaints or lawful intercept requests.

CGNAT public pool sizing determines concurrent session capacity. Each public IP address has 64,511 available ports (1024-65535 for NAT use). At a standard ISP allocation of 1,000 ports per subscriber, one public IP supports approximately 64 concurrent subscribers. A /28 (14 usable addresses) supports around 900 concurrent subscribers. Size the pool for your expected simultaneous active subscriber count at peak, not total subscriber count.

Management addresses must be in a completely separate range from both subscriber and public pool space, with no routing overlap.

Port Block Allocation for Regulatory Logging

Port block allocation is the design decision with the largest regulatory compliance impact. Without it, accurately logging which subscriber used which public IP and port at a specific time requires querying live connection tracking state, which only contains active connections. Connections that have ended cannot be retrospectively attributed to a subscriber.

Port block allocation assigns a fixed block of ports to a specific subscriber IP for a defined time window. The allocation event is logged: subscriber IP, public IP, port block start and end, allocation start time. When a complaint or lawful intercept request arrives referencing a specific public IP and port at a specific time, you query the allocation log rather than live connection state, and the answer is always available regardless of whether the connection is still active.

Standard port block sizes are 128, 256, 512, or 1,000 ports per subscriber. A 1,000-port block per subscriber provides enough ports for typical residential usage patterns while keeping log volume manageable. A 128-port block conserves public IP pool space but can cause port exhaustion for subscribers with many simultaneous connections (video streaming, gaming, torrenting).

The logging requirement for CTDISR-2025 compliance and lawful intercept readiness mandates that these allocation logs are retained for a defined period and are queryable. Store them in a database rather than flat log files for practical query speed on large subscriber populations.

CGNAT Placement in the Network

CGNAT can be performed at the aggregation layer (one CGNAT function per PoP) or at a centralised CGNAT cluster (all subscriber traffic passes through a central function). Both approaches have tradeoffs.

Distributed CGNAT at the aggregation layer reduces traffic volume at the core, keeps latency lower since translation happens closer to the subscriber, and limits the blast radius of a single CGNAT function failure to one PoP's subscribers. The operational complexity is higher: multiple CGNAT instances to manage, logs spread across multiple locations, and public IP pool management across distributed sites.

Centralised CGNAT simplifies log management (all logs in one place), simplifies public IP pool management, and reduces configuration surface area. The tradeoffs are that all subscriber traffic traverses the core network before translation, adding latency, and a single CGNAT cluster failure affects all subscribers simultaneously.

For regional ISPs with up to three or four PoPs, centralised CGNAT is operationally simpler and the latency impact is acceptable if core links are low-latency. For national operators with geographically dispersed PoPs, distributed CGNAT at the regional level with centralised log aggregation is the better architectural choice.

Scalability Patterns

CGNAT function scalability is bounded by connection tracking table size (memory), packet processing rate (CPU), and public IP pool capacity. As subscriber count grows, one or more of these becomes the constraint.

Connection tracking table exhaustion is the first bottleneck in most deployments. Reduce connection tracking timeouts aggressively on the CGNAT router: the default timeout values are designed for small networks and hold entries far longer than CGNAT deployments need. Reducing TCP established timeout from the default 5 days to 1 hour, and UDP timeout from 30 seconds to 20 seconds, dramatically reduces table size at equivalent active subscriber counts.

Horizontal scaling, multiple CGNAT devices with subscriber groups load-balanced across them, is the correct pattern for growth beyond a single device's capacity. Assign subscriber IP ranges to specific CGNAT devices and route accordingly, so each device handles a defined subset of subscribers and log correlation is straightforward.

For the platform-specific implementation on MikroTik, the CGNAT configuration guide on this site covers RouterOS-specific tuning. For CGNAT design as part of a full network architecture engagement, Network Design & Optimization covers addressing, log infrastructure, and scalability planning. For compliance logging requirements under CTDISR-2025, CTDISR Audit Readiness covers what the log evidence needs to demonstrate.