Why IP addresses are no longer a safe bet
IP addresses were long treated as reliable identifiers for geolocation, security, and reputation purposes. Tools like blocklists, rate limiting, and anomaly detection all assume that a single IP address corresponds to a single, accountable entity — maybe even a specific user or device.
That assumption no longer holds. A single IPv4 address can now represent hundreds or thousands of people behind Carrier-Grade NAT (CGNAT), VPNs, or proxies. Applying standard security mechanisms to such addresses causes serious collateral damage, especially in regions where IP sharing is the norm.
This article outlines an approach to detecting large-scale IP sharing globally, building reliable training data for that purpose, and using the results to prevent unintended bias against users in developing regions.
The socioeconomic dimension of IP scarcity
The mismatch between available IPv4 addresses and user populations is unevenly distributed. Many developing countries have both fewer IPs relative to their populations and more users. This is a historical leftover: the largest IPv4 allocations went to organizations in North America and Europe decades ago, leaving smaller pools for regions where Internet adoption happened later.
The inequality becomes visible in country-level ratios of users to IP addresses. Comparing World Bank user estimates with Regional Internet Registry (RIR) allocation records shows that Africa and South Asia have the highest user-to-IP ratios, while Australia, Canada, Europe, and the US have the lowest — despite having the highest per-capita penetration rates.
As Internet penetration grows in the developing world, IPv4 scarcity deepens, pushing ISPs toward even heavier reliance on CGNAT. This is compounded by the prevalence of mobile networks in those regions, which makes heavy use of carrier-grade translation. The result is that IP-based protections would disproportionately affect developing economies, affecting large user populations every time a single shared address is penalized.
When an IP belongs to everyone
Two distinct patterns of large-scale IP sharing exist. VPNs and proxies are the more familiar type: they route many users through a small set of exit IPs, and users are aware of them. CGNAT is different — it happens inside the ISP's access network, without user knowledge or individual consent.
The root cause is technical: IPv4's 32-bit address space supports only 4.3 billion addresses, far too few for the modern Internet. RIRs ran out of unallocated blocks in the early 2010s, so ISPs turned to CGNAT rather than IPv6 to keep growth going. Subscribers are grouped behind a shared public IP, conserving scarce address space. A side benefit is that many home devices remain unreachable from the outside, protected from direct attack.
But the side effects are real. When hundreds or thousands of clients appear behind one IP, an IP-based security action — a block or a throttle — hits everyone behind that address, not just the single user who triggered it. The IETF recognized this issue years ago: RFC 6269 describes the operational and security challenges of address sharing, and RFC 7021 examines how CGNAT breaks many standard network applications.
The UK regulator Ofcom made the practical point in a 2015 report: if a shared IPv4 address is blacklisted as a spam source, the impact is far larger than for a typical residential address — potentially blocking an entire subscriber base. And although IPv6 is the planned solution, CGNAT has become a permanent feature of the network rather than a temporary stopgap.
Building a shared-IP detector
To avoid penalizing innocent users behind shared IPs, we need to identify the addresses where large-scale sharing occurs. This allows traffic filtering to be calibrated correctly, while distinguishing CGNAT from VPNs and proxies, since different mitigation strategies may apply.
Cloudflare's view of active IP clients makes a data-driven approach possible. A supervised learning classifier can separate CGNAT and VPN/proxy IPs from single-subscriber IPs on the basis of behavioral characteristics.
The main obstacle is less algorithmic than empirical: a labeled dataset of CGNAT IPs does not exist, and there is no field in HTTP traffic that indicates an IP is behind CGNAT.
Using public data to find CGNAT traces
To build the training data, we combine several network measurement techniques. Each provides a noisy but independent signal of large-scale sharing:
Distributed traceroutes
CGNAT inserts a sharing step in RFC 6598 shared space, typically between the customer premises equipment (CPE) and the public Internet. Running a traceroute from the client to its own public IP reveals the path hop by hop. If an intermediate hop appears in 100.64.0.0/10, right after a private RFC 1918 address and before the public IP, that is strong evidence of CGNAT.
Traceroutes can also show multi-level NAT, which CGNAT almost always introduces. When a private address appears immediately downstream of the first hop, it indicates at least two NAT layers. ISPs sometimes use private ranges internally without CGNAT, but a consistent pattern of multiple RFC 1918 or shared hops before a public address strongly suggests carrier-grade translation.
Applied to distributed traceroutes from more than 9,000 RIPE Atlas probes, this method reliably classifies hosts as behind CGNAT, behind single-layer NAT, or directly reachable.
PTR, WHOIS, and IRR mining
Operators frequently record information about their IP space in reverse DNS pointer (PTR) records. Querying PTR records across the IPv4 space and filtering for descriptive keywords — such as cgnat, cgn, or lsn — produces signaled-but-reliable indicators of CGNAT blocks. Examples include:
node-lsn.pool-1-0.dynamic.totinternet.net103-246-52-9.gw1-cgnat.mobile.ufone.nzcgn.gsw2.as64098.net
WHOIS and Internet Routing Registry (IRR) records provide complementary clues: organizational names, remarks, and allocation details often reveal whether a block is meant for CGNAT use or residential assignments. Because these records are manually maintained, likely stale, or inconsistently populated, the resulting list is cross-checked against market and customer reports to verify whether the identified ISPs actually run CGNAT.
VPN and proxy collection
Compiling VPN and proxy IPs is comparatively easy. Public anonymizer directories list active exit addresses directly. The approach is also backed by subscribing to multiple VPN providers and harvesting each allocated IP address by connecting to a dedicated HTTP endpoint, ensuring that the observed exits are genuine and active.
Modeling CGNAT with machine learning
Combining the techniques described above produced a labeled dataset of more than 200K CGNAT IPs, 180K VPNs and proxies, and close to 900K allocated IPs that are not large-scale sharing (LSS) IPs. These labels became the input to machine-learning classification.
Feature engineering
The core hypothesis was that aggregated activity from CGNAT IPs is statistically distinguishable from activity from other IP types. Feature extraction tests this hypothesis directly. Because networks don’t publicly disclose CGNAT usage, inference quality is bound to training-data confidence. The key discriminator turned out to be diversity, not sheer volume. VM-hosted scanners may emit high request rates with low informational variety, while globally routable customer premises equipment (CPEs) can be individually distinctive yet generate traffic volumes unlikely to be caught at lower sampling rates.
Features were parsed from a 1% sampled HTTP request log for IPs in the reference set and for their corresponding /24 prefix (IPs sharing the same first 24 bits). Analysis applied the same features to VPNs, proxies, CGNAT, and non-LSS IPs. Broad categories that mattered most:
- Client-side signals — aggregate properties of the clients connecting from each IP. A large, varied user base behind a CGNAT presents far wider statistical variety in client behavior than a single-tenant server or small proxy.
- Network and transport behaviors — artifacts left by large-scale appliances in port allocation and connection timing reveal their presence.
- Traffic volume and destination diversity — an IP fronting thousands of users generates higher request volume and targets a broader, less correlated set of destinations than a single-user IP.
To separate CGNAT from VPNs and proxies, features had to be aggregated at two scopes: per-IP and per-/24 prefix. CGNAT IPs tend to be allocated in contiguous blocks; VPN IPs scatter across prefixes.
Classification results
Features were computed from HTTP logs over 24-hour intervals to boost data volume and reduce noise from DHCP reallocation. The dataset split 70/30 into training and test sets with disjoint /24 prefixes. VPN and proxy labels were merged, given their similarity and lower operational importance next to CGNAT detection.
A multi-class XGBoost model was trained with class weighting for imbalance, assigning each IP to the highest-probability class. XGBoost handles large feature sets well, provides regularization, and needs little tuning. The classifier reached 0.98 accuracy, 0.97 weighted F1, and 0.04 log loss. The figure below shows its confusion matrix.
Errors mostly appear when VPN/proxy IPs sit inside a /24 prefix also shared with broadband users. Predictions were further validated with 10-fold cross-validation: macro-average Area Under the ROC Curve (AUC) reached 0.9946 (σ=0.0069) and log loss 0.0429 (σ=0.0115). Prefix-level features contributed most to classification.
Rate limiting hits CGNAT users harder
The figure below tracks daily CGNAT inferences from the CDN-deployed detection service between December 17, 2024, and January 9, 2025. Counts stayed largely stable, with dips on weekends and holidays like Christmas and New Year’s Day — consistent with seasonal traffic variation.
IP-reputation- or behavior-based actions can be skewed by CGNAT. Bot detection, however, proved resilient. An evaluation looked at how often requests from CGNAT and non-CGNAT IPs receive bot labels. Cloudflare assigns a bot score per request via CatBoost models, surfaced through the Web Application Firewall (WAF) for customer filtering rules.
Median bot rates were nearly equal — 4.8% for CGNAT versus 4.7% for non-CGNAT IPs. Mean rates differed more sharply: 7% for CGNAT versus 13.1% for non-CGNAT. Non-CGNAT IPs spread widely, with some at 100% bot rates; CGNAT IPs clustered below 15%. Non-CGNAT IPs skew toward either mostly-human or mostly-bot activity, while CGNAT IPs reflect the mixed behavior of many end users, dominated by human traffic.
Despite bot scores suggesting more human traffic, CGNAT IPs were rate limited three times more often than non-CGNAT IPs. The likely cause: multiple users share one public IP, so legitimate traffic easier collides with customers' bot mitigation and firewall rules. Users behind CGNAT do suffer collateral effects. Identifying those IPs enables mitigation that disrupts malicious traffic while sparing benign users behind the same address.
CGNAT ecosystems across the globe
A motivating question behind this work was whether IP-address knowledge hides socio-economic bias — in particular, whether actions on an IP may disproportionately affect the Global South. Identifying where CGNAT IPs exist is the first step.
The map below shows each country’s fraction of inferred CGNAT IPs over IPs observed in that country. Darker regions rely more heavily on CGNAT; Africa and Central and Southeast Asia show the strongest reliance.
Continental differences also show in the boxplot below, which displays the distribution of distinct user agents per IP across /24 prefixes inferred to be CGNAT deployments per continent.
Africa stands out with a much higher user-agent-to-IP ratio, implying more clients share each IP in African autonomous systems. African ISPs not only rely on CGNAT more extensively — more subscribers sit behind each address.
Country-level CGNAT deployment rates align with users-per-IP ratios, although deployment alone doesn’t confirm the ratio. The scatterplot below compares APNIC user estimates with IP counts per ASN in CGNAT-detected ASNs. ASNs below the diagonal have fewer addresses than users. Notably, many ASNs with more addresses than users still run CGNAT — presumably because they offer services beyond broadband and can’t dedicate their full address pool to subscribers.
What this means for end users
Accurate CGNAT detection limits collateral damage from network operations and keeps security measures fair and effective. Findings highlight geographic and socio-economic disparities in IP sharing methods. The detection systems are already being used to review policies and improve the application security suite, and work with customers on applying these insights to their protections. ISPs and network operators running CGNAT can contribute at [email protected]; shared knowledge supports a more equitable experience while preserving web service security. Work is ongoing and more details will be published as available.
