| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| design:ip_classification [2026/08/12 09:22] – Refresh all corpus figures for the extended 2010-2026 extraction (4,322 -> 5,859 papers; IP-classifying 234 -> 295). ip_fold.mjs extended to fold 18 new residue strings back to zero; report script's hardcoded 234 denominators and open-ended 2022+ bucket f karel.kubicek.claude | design:ip_classification [2026/08/21 14:50] (current) – Boxes: <wrap> renders a span, use uppercase <WRAP>; one box per list, not per bullet karel.kubicek.claude |
|---|
| | Is it the //same host// as last week? | Nothing reliable | Bad. Assume no unless you can show otherwise | — | | | Is it the //same host// as last week? | Nothing reliable | Bad. Assume no unless you can show otherwise | — | |
| |
| The rows are in descending order of defensibility, and papers reach for the bottom rows far more often than the top ones. Of the 234 papers in our corpus that classify an IP address, 92 name a geolocation source and only 53 name a routing or ASN source (see [[#Use in Publications]]) — even though the routing answer is the one that is nearly always correct. | The rows are in descending order of defensibility, and papers reach for the bottom rows far more often than the top ones. Of the 295 papers in our corpus that classify an IP address, 114 name a geolocation source and only 68 name a routing or ASN source (see [[#Use in Publications]]) — even though the routing answer is the one that is nearly always correct. |
| |
| <WRAP important> | <WRAP important> |
| * **Playwright**: ''await response.serverAddr()'' → ''{ipAddress, port}''. | * **Playwright**: ''await response.serverAddr()'' → ''{ipAddress, port}''. |
| * **Chrome DevTools Protocol** (so also Puppeteer, and OpenWPM through its instrumentation): ''Network.responseReceived'' → ''e.response.remoteIPAddress'' and ''remotePort''. | * **Chrome DevTools Protocol** (so also Puppeteer, and OpenWPM through its instrumentation): ''Network.responseReceived'' → ''e.response.remoteIPAddress'' and ''remotePort''. |
| * **A HAR file**: the per-entry ''serverIPAddress'' field, which HAR 1.2 defines and Chrome, Firefox and Playwright all populate. (More on working with HAR: [[Programming:Traffic files]], not yet written.) | * **A HAR file**: the per-entry ''serverIPAddress'' field, which HAR 1.2 defines and Chrome, Firefox and Playwright all populate. (More on working with HAR: [[Programming:Traffic files]].) |
| |
| Measured on one page load of ''https://www.bbc.com/'' on 6 August 2026: all 130 responses carried an address via Playwright and via CDP; the HAR was missing one, a beacon still in flight when the context closed. So take it from the live event stream if you can, and treat a HAR as very slightly lossy. | Measured on one page load of ''https://www.bbc.com/'' on 6 August 2026: all 130 responses carried an address via Playwright and via CDP; the HAR was missing one, a beacon still in flight when the context closed. So take it from the live event stream if you can, and treat a HAR as very slightly lossy. |
| * **[[https://asdb.stanford.edu/|ASdb]]** {[ziv2021_asdb]} classifies ASNs into 17 industry categories and 95 sub-categories (hosting, ISP, education, government…), reporting 96% coverage of ASes at 93% accuracy on the top level and 75% on sub-categories. Snapshots run through March 2026. Used, for example, by {[darwich2023_replication]} to describe what kind of networks their geolocation targets sat in. | * **[[https://asdb.stanford.edu/|ASdb]]** {[ziv2021_asdb]} classifies ASNs into 17 industry categories and 95 sub-categories (hosting, ISP, education, government…), reporting 96% coverage of ASes at 93% accuracy on the top level and 75% on sub-categories. Snapshots run through March 2026. Used, for example, by {[darwich2023_replication]} to describe what kind of networks their geolocation targets sat in. |
| |
| <wrap todo>**CAIDA's separate //AS Classification// dataset is discontinued** — CAIDA's own page states it is no longer supported and download access has been removed. Papers from 2015–2022 cite it routinely; ASdb is the live replacement. Check before you cite a dataset you found in a related-work section.</wrap> | <WRAP todo>**CAIDA's separate //AS Classification// dataset is discontinued** — CAIDA's own page states it is no longer supported and download access has been removed. Papers from 2015–2022 cite it routinely; ASdb is the live replacement. Check before you cite a dataset you found in a related-work section.</WRAP> |
| |
| The current state of the art on the sibling problem is {[selmo2025_borges]} (IMC 2025), which few-shot prompts an LLM over PeeringDB free-text fields plus website and domain evidence, and reports a 7% improvement in sibling-ASN identification over AS2Org-style methods. That is, as of 2026, **the one place in IP classification where an LLM method has cleared peer review** — see [[#Open Questions]]. | The current state of the art on the sibling problem is {[selmo2025_borges]} (IMC 2025), which few-shot prompts an LLM over PeeringDB free-text fields plus website and domain evidence, and reports a 7% improvement in sibling-ASN identification over AS2Org-style methods. That is, as of 2026, **the one place in IP classification where an LLM method has cleared peer review** — see [[#Open Questions]]. |
| ==== Ask the operator first ==== | ==== Ask the operator first ==== |
| |
| The most accurate datacenter detection is free, authoritative and almost unused in this literature: **the cloud and CDN operators publish their own prefix lists.** Grepping the full text of all 4,322 papers in the corpus for the URLs below finds them in **six**.((Full-text grep of `paper.cols.txt` for `ip-ranges.amazonaws`, `gstatic.com/ipranges`, `cloudflare.com/ips`, `public_ip_ranges.json` or `ServiceTags_Public`, run 2026-08-06. Six papers, all network-measurement rather than web-privacy. This undercounts papers that used a list without citing its URL, so read it as a floor.)) | The most accurate datacenter detection is free, authoritative and almost unused in this literature: **the cloud and CDN operators publish their own prefix lists.** Grepping the full text of all 5,859 papers in the corpus for the URLs below finds them in **seven**.((Full-text grep of `paper.cols.txt` for `ip-ranges.amazonaws`, `gstatic.com/ipranges`, `cloudflare.com/ips`, `public_ip_ranges.json` or `ServiceTags_Public`, re-run 2026-08-12 against the extended corpus. Seven papers, all network-measurement rather than web-privacy; the seventh, added with the 2025 venue-year, is //Secure IP Address Allocation at Cloud Scale// (NDSS 2025). This undercounts papers that used a list without citing its URL, so read it as a floor.)) |
| |
| All of the following were fetched and confirmed serving on 6 August 2026: | All of the following were fetched and confirmed serving on 6 August 2026: |
| * **GreyNoise** covers Internet-wide scanners specifically, and — unusually — runs a free [[https://docs.greynoise.io/docs/vip-program|Research Community programme]] giving students and independent researchers non-commercial access to the full enterprise API. If you need this class of data for a paper, ask them before you pay anyone. | * **GreyNoise** covers Internet-wide scanners specifically, and — unusually — runs a free [[https://docs.greynoise.io/docs/vip-program|Research Community programme]] giving students and independent researchers non-commercial access to the full enterprise API. If you need this class of data for a paper, ask them before you pay anyone. |
| |
| Only 13 of the 234 IP-classifying papers in the corpus name a feed of this kind, and **all but one are from 2019 or later** (the exception is 2018) — this is the newest of the five questions and the least settled. | Only 17 of the 295 IP-classifying papers in the corpus name a feed of this kind, and **all but one are from 2019 or later** (the exception is 2018) — this is the newest of the five questions and the least settled. |
| |
| <WRAP important> | <WRAP important> |
| * The threshold may be fragile in exactly the conditions a real client has. {[chiapponi2023_poster]} probed the RTT delta from one laptop and one handset in France, 20 connections per configuration, and found the handset on 4G at **51.5 ± 14.5 ms** — over a 50 ms threshold with no proxy present — while a browser rather than a script, or a Wi-Fi hotspot, each added delay without individually crossing it. It is a two-page poster on a single carrier (SFR), and the authors themselves attribute the 4G result to that carrier running a transparent proxy, so read it as a warning to calibrate on your own population rather than as a general false-positive rate. | * The threshold may be fragile in exactly the conditions a real client has. {[chiapponi2023_poster]} probed the RTT delta from one laptop and one handset in France, 20 connections per configuration, and found the handset on 4G at **51.5 ± 14.5 ms** — over a 50 ms threshold with no proxy present — while a browser rather than a script, or a Wi-Fi hotspot, each added delay without individually crossing it. It is a two-page poster on a single carrier (SFR), and the authors themselves attribute the 4G result to that carrier running a transparent proxy, so read it as a warning to calibrate on your own population rather than as a general false-positive rate. |
| |
| Earlier and complementary: {[weinberg2018_catch]} used active geolocation to show that 638 of 2,269 advertised proxy locations were false, 401 of them not even on the right continent. Work published after our corpus closes continues this line — Ali et al., [[https://www.ndss-symposium.org/ndss-paper/beyond-rtt-an-adversarially-robust-two-tiered-approach-for-residential-proxy-detection/|"Beyond RTT: An Adversarially Robust Two-Tiered Approach for Residential Proxy Detection"]] (NDSS 2026), is explicitly a response to the fragility above — so check for something newer than 2024 before you build your own. | Earlier and complementary: {[weinberg2018_catch]} used active geolocation to show that 638 of 2,269 advertised proxy locations were false, 401 of them not even on the right continent. The line continues into the corpus's newest venue-year — Ali et al., [[https://www.ndss-symposium.org/ndss-paper/beyond-rtt-an-adversarially-robust-two-tiered-approach-for-residential-proxy-detection/|"Beyond RTT: An Adversarially Robust Two-Tiered Approach for Residential Proxy Detection"]] (NDSS 2026), is explicitly a response to the fragility above — so check for something newer still before you build your own. |
| |
| ===== IP as an Identifier: Four Ways It Breaks ===== | ===== IP as an Identifier: Four Ways It Breaks ===== |
| **IPv6 is different, and in the direction people do not expect.** The intuition is that IPv6 clients rotate temporary addresses ([[https://www.rfc-editor.org/rfc/rfc8981.html|RFC 8981]]) and are therefore harder to track. That is true of the interface identifier and false of the assignment: {[padmanabhan2020_dynamips]} found that **IPv6 assignments last //longer// than IPv4 ones, often remaining stable for months** — which makes long-term tracking of an IPv6 subscriber //easier//, not harder.((Paraphrased rather than quoted: we verified the paper, venue and topic against Crossref and the authors' own listing, but could not reach a copy to quote the sentence verbatim. Check it before citing the wording.)) Aggregate on the /64 or the delegated prefix, not the full address, and do not assume dual-stack clients are equally identifiable on both stacks. Where hardware still derives the interface identifier from a MAC address, the address is //more// identifying than IPv4 ever was: {[rye2023_ipvseeyou]} extracted EUI-64-derived MACs from over 12M routers in 146 countries and geolocated them by correlating with wardriving data, reporting a **median error of 39 metres**. For the same devices, MaxMind's locations sat a median **26 km** from those wardriving positions — three orders of magnitude apart, from the same input address. | **IPv6 is different, and in the direction people do not expect.** The intuition is that IPv6 clients rotate temporary addresses ([[https://www.rfc-editor.org/rfc/rfc8981.html|RFC 8981]]) and are therefore harder to track. That is true of the interface identifier and false of the assignment: {[padmanabhan2020_dynamips]} found that **IPv6 assignments last //longer// than IPv4 ones, often remaining stable for months** — which makes long-term tracking of an IPv6 subscriber //easier//, not harder.((Paraphrased rather than quoted: we verified the paper, venue and topic against Crossref and the authors' own listing, but could not reach a copy to quote the sentence verbatim. Check it before citing the wording.)) Aggregate on the /64 or the delegated prefix, not the full address, and do not assume dual-stack clients are equally identifiable on both stacks. Where hardware still derives the interface identifier from a MAC address, the address is //more// identifying than IPv4 ever was: {[rye2023_ipvseeyou]} extracted EUI-64-derived MACs from over 12M routers in 146 countries and geolocated them by correlating with wardriving data, reporting a **median error of 39 metres**. For the same devices, MaxMind's locations sat a median **26 km** from those wardriving positions — three orders of magnitude apart, from the same input address. |
| |
| <wrap todo>Before you use an IP as a user identifier, write down which of these four you have ruled out and how. If the answer is "none", use it as a network identifier (prefix or ASN) instead, where all four are far weaker.</wrap> | <WRAP todo>Before you use an IP as a user identifier, write down which of these four you have ruled out and how. If the answer is "none", use it as a network identifier (prefix or ASN) instead, where all four are far weaker.</WRAP> |
| |
| ===== A Script ===== | ===== A Script ===== |
| * **Folding.** ''scripts/ip_fold.mjs'' maps 443 distinct free-text names onto ordered regex families, specific products before the generic term they contain, and returns anything unmatched. Residue is zero and is printed on every run — but it was **18 strings** when the corpus grew to 2026 and had to be extended; see [[provenance:design:ip_classification]] for what was added and where each new string went. The families are ours, not the papers': ''Other IP blocklists'' merges a dozen services that are not interchangeable. | * **Folding.** ''scripts/ip_fold.mjs'' maps 443 distinct free-text names onto ordered regex families, specific products before the generic term they contain, and returns anything unmatched. Residue is zero and is printed on every run — but it was **18 strings** when the corpus grew to 2026 and had to be extended; see [[provenance:design:ip_classification]] for what was added and where each new string went. The families are ours, not the papers': ''Other IP blocklists'' merges a dozen services that are not interchangeable. |
| * **Field stability.** The enums (''method'', ''validation'', ''target'') are reproducible on a repeat extraction to within a few points. Free-text resource names are ~20% stable by exact string, which is why they appear here only as folded rankings. | * **Field stability.** The enums (''method'', ''validation'', ''target'') are reproducible on a repeat extraction to within a few points. Free-text resource names are ~20% stable by exact string, which is why they appear here only as folded rankings. |
| * **Venue coverage.** EuroS&P, ACSAC, RAID, AsiaCCS, CHI and SOUPS are absent, as are the venues where much of this work actually appears — **PAM, TMA, ANRW, SIGCOMM and ACM CCR are not in the corpus**, and for IP geolocation specifically that is a serious gap. Any claim here is a claim about seven venues. | * **Venue coverage.** Seven venues only — the scope and the selection funnel are on [[literature:corpus]]. For //this// topic the venues where much of the work actually appears are all absent: **PAM, TMA, ANRW, SIGCOMM and ACM CCR are not in the corpus**, and for IP geolocation specifically that is a serious gap. |
| * **The corpus reaches 2026, but its last two years are provisional.** CCS and IMC 2026 have not been held and two more 2026 venue-years are incompletely selected, so a per-period row ending in 2025–2026 rests on fewer papers than a complete window would give. The "current in 2026" judgements on this page are ours, checked against vendor and standards documentation, not derived from the corpus. | * **The corpus reaches 2026, but its last two years are provisional** (see [[literature:corpus]]), so a per-period row ending in 2025–2026 rests on fewer papers than a complete window would give. The "current in 2026" judgements on this page are ours, checked against vendor and standards documentation, not derived from the corpus. |
| * **Every query behind this section, the report script and its unedited output** are on [[provenance:design:ip_classification]]; corpus-level caveats are on [[literature:corpus]]. | * **Every query behind this section, the report script and its unedited output** are on [[provenance:design:ip_classification]]; corpus-level caveats are on [[literature:corpus]]. |
| |
| ===== Open Questions ===== | ===== Open Questions ===== |
| |
| * <wrap todo>**No head-to-head of the geolocation databases on a web-measurement population.** {[gharaibeh2017_look]} used router interfaces (2017), {[darwich2023_replication]} RIPE Atlas anchors (2023), {[nabi2026_lostprefix]} Atlas and Giga (2026). None of them is "the servers a Tranco top-10k crawl connects to" — a population dominated by CDN and cloud edges, which is exactly the population the anycast and datacenter caveats bite hardest on.</wrap> | <WRAP todo> |
| * <wrap todo>**How much does the choice of database move a published cross-border-transfer figure?** Re-running one compliance paper's analysis with four databases would be a small, cheap, useful replication, and the answer is not obviously small: the run above disagreed on country for the AWS edge.</wrap> | * **No head-to-head of the geolocation databases on a web-measurement population.** {[gharaibeh2017_look]} used router interfaces (2017), {[darwich2023_replication]} RIPE Atlas anchors (2023), {[nabi2026_lostprefix]} Atlas and Giga (2026). None of them is "the servers a Tranco top-10k crawl connects to" — a population dominated by CDN and cloud edges, which is exactly the population the anycast and datacenter caveats bite hardest on. |
| * <wrap todo>**Geofeed adoption is not measured for the web.** {[livadariu2024_geofeeds]} gives 1.50% of allocated IPv4 prefixes overall; nobody has asked what share of the //address space a crawl actually touches// has a geofeed, which — given how concentrated that space is on a few large operators — could be much higher or much lower.</wrap> | * **How much does the choice of database move a published cross-border-transfer figure?** Re-running one compliance paper's analysis with four databases would be a small, cheap, useful replication, and the answer is not obviously small: the run above disagreed on country for the AWS edge. |
| * <wrap todo>**No systematic evaluation of the commercial datacenter/VPN/proxy flags against ground truth.** Every paper that uses one takes it on faith, and the run above shows two public DNS resolvers flagged ''is_vpn'' and ''is_abuser''. A labelled benchmark here would be immediately useful and is well within a single student's reach.</wrap> | * **Geofeed adoption is not measured for the web.** {[livadariu2024_geofeeds]} gives 1.50% of allocated IPv4 prefixes overall; nobody has asked what share of the //address space a crawl actually touches// has a geofeed, which — given how concentrated that space is on a few large operators — could be much higher or much lower. |
| * <wrap todo>**No peer-reviewed method for identifying hosting/datacenter address space** beyond the operators' own published lists — which means everything outside the big five clouds is guesswork.</wrap> | * **No systematic evaluation of the commercial datacenter/VPN/proxy flags against ground truth.** Every paper that uses one takes it on faith, and the run above shows two public DNS resolvers flagged ''is_vpn'' and ''is_abuser''. A labelled benchmark here would be immediately useful and is well within a single student's reach. |
| * <wrap todo>**LLMs have reached AS-to-organisation mapping {[selmo2025_borges]} but not IP classification.** We found nothing peer-reviewed applying an LLM to geolocation, host typing or residential/VPN/datacenter labelling as of August 2026 — unlike cookie and policy classification, where LLM methods are now routine. Whether that is because the task has no useful text to read, or because nobody has tried, is an open question.</wrap> | * **No peer-reviewed method for identifying hosting/datacenter address space** beyond the operators' own published lists — which means everything outside the big five clouds is guesswork. |
| * <wrap todo>**No strong successor to {[richter2016_multi]} on CGNAT prevalence.** The best numbers on how much of the client Internet sits behind shared addresses are a decade old, and IPv4 exhaustion has only got worse since.</wrap> | * **LLMs have reached AS-to-organisation mapping {[selmo2025_borges]} but not IP classification.** We found nothing peer-reviewed applying an LLM to geolocation, host typing or residential/VPN/datacenter labelling as of August 2026 — unlike cookie and policy classification, where LLM methods are now routine. Whether that is because the task has no useful text to read, or because nobody has tried, is an open question. |
| | * **No strong successor to {[richter2016_multi]} on CGNAT prevalence.** The best numbers on how much of the client Internet sits behind shared addresses are a decade old, and IPv4 exhaustion has only got worse since. |
| | </WRAP> |
| |
| ===== Related Pages ===== | ===== Related Pages ===== |
