Title: A Global Inference and Assessment of Large Shared IP Addresses
Authors: Vasileios Giotsas, Antoine Cordelle, Nick Wood, Marwan Fayed (Cloudflare, Inc.); Loqman Salamatian (Columbia University)
Scribe: Ziyi Wang (Xiamen University)
Introduction:
Internet services often treat IP addresses as identifiers for users or devices and use them for access control, rate limiting, and malicious traffic detection. However, large shared IP addresses, including Carrier-Grade NATs (CGNs), VPN exit nodes, and enterprise proxies, may serve hundreds or even thousands of unrelated users. These addresses are referred to as multi-user IP addresses, or M-IPs. If services continue to treat source IPs as roughly equivalent, abnormal traffic generated by a single user or device may trigger blocking or rate limiting for the entire IP address and affect legitimate users who happen to share it.
Accurately identifying M-IPs is difficult. Network operators rarely disclose their internal address-sharing configurations, public measurement datasets have limited coverage, and both IP assignments and CGN address pools change over time. This paper studies how to identify large shared IP addresses at Internet scale using noisy, heavily sampled network logs. It then examines how CGNs relate to user performance, IPv6 deployment, regional distribution, and security policies. Figure 1 shows that the number of Internet users per IPv4 address varies substantially across countries. The ratio is particularly high in parts of Africa and South Asia, which means that IP-level actions may have very different consequences across regions.
Key idea and contribution:
The central question of this paper is how to determine whether a public IP address is shared by a large number of users and whether it belongs to a CGN, a VPN or proxy, or a regular non-shared IP. The authors first construct a reference dataset of multi-user IP addresses using public sources such as RIPE Atlas, DNS PTR records, Censys, and Shodan. They then combine this dataset with global CDN request logs and extract behavioral features such as User-Agent diversity, TLS fingerprints, source-port usage, RTT variability, and destination-domain diversity. Figure 2 shows a typical CGN/NAT444 setting and explains why traceroute can provide useful signals for identifying CGNs.
The key insight is that identifying shared IPs is not simply about asking “how much traffic does this IP generate?”, but rather “how many different users’ behaviors are mixed behind this IP?” For CGNs, users’ connections are dynamically mapped onto a contiguous pool of public IP addresses, so an individual IP reveals only a partial view of the overall population behavior. Only after aggregating behavior across the entire /24 prefix do the diversity of users, devices, and access-network paths become clearly visible. In other words, the paper’s main contribution is not the use of XGBoost itself, but the finding that prefix-level behavioral diversity is a much stronger indicator of large-scale address sharing than single-IP behavior.
Figure 10 captures this result most clearly. Most of the highest-ranked features come from /24 prefix-level aggregates rather than from individual IP addresses. When the model uses only IP-level features, the macro F1 score falls to 0.57, showing that classification performance degrades substantially without /24-level aggregation.
To test whether this finding depends on Cloudflare’s proprietary data, the authors also build a second CGN detection model using the public M-Lab NDT tcpinfo dataset. This model uses transport-layer features such as temporal activity, ephemeral-port usage, PMTU and MSS variability, and destination diversity instead of the application-layer features used by the CDN model. Even with a completely different data source and feature set, the public model achieves an AUC of 0.97 and an accuracy of 94%. This suggests a broader principle: when many users share the same address pool, their combined activity leaves stable and identifiable statistical patterns in aggregated network behavior.
Evaluation:
On the held-out test set, the CDN multi-class classifier achieves an accuracy of 0.98, a weighted F1 score of 0.97, and a log loss of 0.04. In 10-fold cross-validation with disjoint /24 prefixes, the macro-average AUC reaches 0.99. The model also correctly classifies 96% of an independent set of 368 live SOCKS4/SOCKS5 proxy IP addresses. When applied to CDN logs from April 29, 2025, the model identifies more than 40 million CGN IPs across 14,319 ASNs and more than 2 million VPN/Proxy IPs across 22,696 ASNs. The confusion matrix in Figure 9 further supports the model’s ability to distinguish the three address classes.
The public M-Lab model achieves an AUC of 0.97 and an accuracy of 94% over the address space that overlaps with the CDN observations. This confirms that address sharing leaves reproducible behavioral signals across different data sources. At the same time, M-Lab covers only 64.6% of the CGN prefixes inferred by the CDN model, which highlights the coverage limitations of public measurement platforms.
The paper also examines the practical impact of CGNs. First, CGNs do not appear to cause a large decline in average network performance. Within the same ISP and city, the differences in median RTT and throughput between CGN and non-CGN prefixes are generally small. The more important issue is fate sharing. Although the median bot-request rates for CGN and non-CGN IPs are very similar, at 4.8% and 4.7% respectively, CDN customers are about three times more likely to rate-limit CGN traffic, as shown in Figure 13. The paper also finds that large IPv6 deployments often coexist with large CGN pools. This indicates that even networks with extensive IPv6 deployment may still rely on CGNs to provide access to IPv4-only services. Taken together, these results show that using an IP address as a proxy for a user when applying rate limits or blocks can systematically affect legitimate users who share that address. The consequences can be especially severe in regions where IPv4 address space is scarce.
Q1: I was wondering more about the downstream use of your filter. Now that you can distinguish CGN IPs from non-CGN IPs, what do you do with that information as a CDN? Does that mean you do not block those IP addresses? If so, I could imagine attackers starting to hide behind CGN IPs. What should you do after identifying them?
A1: This is a fair concern. We do try to identify spoofed signal behavior and compare it with signals from actual deployments. What I presented here was only a very high-level overview of our inference. In practice, the system is much more involved because it also needs to account for attackers who may try to spoof these signals or exploit the way CGNs are treated.
Q2: What if malicious actors want to bypass certain policies and make themselves appear to be behind a CGN? Can your methodology detect that or be improved to handle it?
A2: The question is what happens if a malicious actor tries to hide behind a CGN so that they are not treated as harshly as non-CGN addresses. This is a trade-off that we are concerned about. However, what we observe is that attackers are opportunistic in most cases. For example, a botnet usually tries to infect as many IPs as possible and is not very selective. We also have the advantage of being able to observe IP behavior over long periods of time, which helps us distinguish normal NAT usage from this kind of abnormal behavior.
Q3: My question is about the measurement vantage point. Your analysis is mainly from Cloudflare’s perspective. Cloudflare is certainly a very large vantage point, but it may still have its own biases. For example, some countries may use Cloudflare less than others. The M-Lab results also suggest that the picture changes somewhat. Does this mean that, to really solve this problem, we need some form of global collaboration or shared view of this information?
A3: That would certainly be ideal. It would also be a very good direction for future work. If we could collaborate with other operators and combine our data with data from operators that have better visibility in Africa or other regions, that would be very valuable. Hopefully, as we talk more about this work and make it more widely known, we will have opportunities for this kind of collaboration.
Personal thoughts
I particularly appreciate that the paper goes beyond simply “detecting X” and connects technical measurement with the broader consequences of how such measurements are used. Rather than treating fate-sharing and the disproportionate impact on the Global South as side observations, the paper places them close to the center of its argument. It highlights an easily overlooked fact: given the highly uneven global distribution of IPv4 address space, an apparently neutral IP-level rate-limiting policy may produce systematically unequal effects across different regions.