{"id":"f0e7ea54-0059-4cf9-9e98-b2b255965d42","arxiv_id":"2411.13799","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A systematic IPv6 scan using three seedlists and eleven generators discovered 6,658 IoT deployments, and found that two generators cover 95% of the discovered deployments.","lead":"This paper combined three IPv6 address lists and eleven address generators to scan about 14 billion addresses, finding 6,658 Internet of Things (IoT) services reachable over IPv6. It reports that these IPv6 IoT deployments are almost as insecure as IPv4 ones, with only 6.2% using TLS and 39% lacking access control.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Post-hoc selection of 6Scan/6Graph makes the 95% coverage claim in-sample; temporal holdout is needed before prescribing this recipe for future IPv6 IoT scans.","rationale":"The reader's weakest assumption is representativeness; my concern is related but narrower and more directly tied to the strongest claim. The 95% number is a property of the found set, and the paper is careful to say 'found deployments.' However, the abstract and conclusion convert it into practical guidance for future scans, and that conversion requires out-of-sample stability. A temporal holdout is the most direct way to distinguish a stable structural property of IPv6 IoT deployments from a post-hoc selection artifact. I do not see an internal inconsistency in the measurements; the issue is the strength of the prescriptive inference. The verdict should remain conditional, but acceptance should require either an out-of-sample replication of the two-generator recipe or a softened claim that does not imply near-full coverage of future IPv6 IoT deployments.","tokens_in":14818,"tokens_out":6314,"duration_ms":61533,"concrete_test":"Run a second, independent scan campaign at a later date (e.g., 3–6 months afterward) with fresh TUM, DNS-zone, and IPv4-derived seedlists. Before running it, fix the recipe to 'all three seedlists plus 6Scan and 6Graph on DNS(www)' exactly as Section IV recommends, and use the same protocol scanners and validation pipeline. Let D_new be the deployments found in the second campaign that were not among the first campaign's 6,658. Compute the recipe's coverage of D_new and compare it with the 95% in-sample figure. If coverage drops materially (e.g., below 90%) or a different generator pair performs substantially better, the Section IV claim is overfit and the paper should either soften the recipe or add a validation split.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section IV's central practical takeaway is that 6Scan and 6Graph on DNS (www), together with all hitlists, cover 95% of deployments. That figure is computed on the same corpus used to choose the two generators: the generator list has 11 members, and choosing the apparent best two after seeing the full result set is a model-selection step, so the reported 95% is an in-sample score rather than a validated prediction for a future campaign. The dataset is also heavily backend-dominated (6650 backend vs. 8 device deployments, Section III-B) and cloud/Content-AS concentrated for MQTT (Section V), so the selected pair could simply be the best fit for this particular mix of seedlist vintage, scan date, and AS composition. Section VI explicitly disclaims any reliable estimate of what fraction of all IPv6 installations was covered, so '95% of found deployments' cannot be promoted to a coverage guarantee for future IoT studies. The measurements are plausible; the unsupported part is the recipe's external validity.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a methodology to discover IPv6-reachable IoT deployments by combining three seedlists (TUM hitlist, DNS AAAA records, and IPv4 scan data) with eleven IPv6 address generators, then scanning four IoT protocols (AMQP, MQTT, OPC UA, CoAP) on standard and (D)TLS ports. The authors report 6,658 valid IPv6 deployments, trace their provenance across the seedlists and generators, and claim that two generators (6Scan and 6Graph on DNS (www)) together with all seedlists cover 95% of the found deployments. They also compare security configurations with IPv4, finding that only 39% of IPv6 deployments have access control and 6.2% use (D)TLS. The paper releases the scanning tools publicly.","tokens_in":15134,"tokens_out":6174,"duration_ms":54592,"significance":"The paper addresses a genuine gap in Internet-wide IoT studies, which have so far focused almost exclusively on IPv4, and it provides a reproducible combination of established IPv6 hitlists and generators. The validation pipeline—TCP and (D)TLS handshakes plus protocol-conformant application-layer requests—is sensible, and the authors take care with deduplication, aliasing, and ethical scanning constraints. If taken as a descriptive account of the discovered sample, the paper offers useful quantitative evidence about the findability, provenance, and security configuration of IPv6 IoT backends, and the open-source tooling is a valuable community resource. The main reservation is that the central prescriptive claim, that two generators suffice, is derived from the same dataset used to select those generators, so its external validity is not yet established.","major_comments":[{"comment":"The '95% coverage' claim is computed on the same dataset that was used to select 6Scan and 6Graph as the best two generators. Because the selection is made after observing the full outcome matrix across all eleven generators and five seedlists, the 95% figure is an in-sample statistic rather than a validated prediction for a future scan campaign. To support the paper's guidance for future IPv6 IoT studies, please add a holdout validation (for example, select generators on one per-protocol scan date and evaluate on another date, or perform a leave-one-seedlist-out cross-validation) or explicitly reposition the claim as a descriptive summary of this campaign rather than a recipe for future studies.","section":"Section IV, Fig. 2"},{"comment":"The security statistics (39% no access control, 6.2% TLS) are presented in the abstract as general characteristics of 'deployments,' but they are computed from a sample in which 6,650 of 6,658 deployments are AMQP/MQTT backends (Section III-B), and the paper itself notes (Section V) that the concentration in content/cloud ASes 'might bias our result.' In addition, Section VI explicitly disclaims any reliable estimate of what fraction of the IPv6 installation space was covered. Please qualify all security claims as applying to the discovered sample of AMQP/MQTT backends, or add a robustness analysis stratified by AS type and protocol to provide a quantitative basis for broader generalization.","section":"Abstract and Section V"},{"comment":"The paper does not show the exact computation behind the 95% coverage claim. Please define it as (seedlist-only deployments plus additional deployments found only by the chosen generators) divided by total valid deployments, and ideally present an incremental coverage curve so readers can verify how the 95% is reached. Without this, it is difficult to assess how much of the claimed sufficiency is due to the two generators versus the already-strong seedlist baseline of 5,890 deployments.","section":"Section IV"}],"minor_comments":[{"comment":"The sentence 'With 24 additionally found deployments, information from IPv4 scans have still a low, but the comparably highest gain in comparison to the TUM list' is hard to parse; please rephrase for clarity.","section":"Section IV"},{"comment":"Figure 1 is dense and the three panels are not clearly labeled in the caption; please enlarge the fonts and add explicit panel descriptions (e.g., 'Base', 'Gain', 'Generators').","section":"Figure 1"},{"comment":"Please state explicitly which generators were run with reduced input sizes beyond 6VecLM, and discuss how such reductions might bias the generated address sets.","section":"Section III-A3"},{"comment":"The phrase 'operators \"hide\" several non-IoT-related services' attributes intent to observed behavior; consider rewording to 'indicates that many non-IoT services are reachable on these ports.'","section":"Section III-B"},{"comment":"The header cells in Table II contain confusing line breaks and stray labels such as '1 Distinct'; please reformat the table so that the column structure is immediately readable.","section":"Table II"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a well-executed measurement study with a reproducible methodology and open-source artifacts. The principal risk is the in-sample selection of the two generators, which should be addressed with a holdout analysis before publication. The paper fits the journal's scope, and I do not see concerns about novelty overlap given its focus on IoT-specific protocols and IPv6 generator combinations."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThis paper gives the IPv6 measurement community the first systematic comparison of address generators for finding IoT deployments. It combines three seedlists and eleven generators, scans four protocols, validates with protocol-conformant handshakes, and traces each of the 6,658 found deployments back to its source. That tracing is the real contribution: it lets the authors show that the TUM open hitlist, filtered for web liveness, drops IoT hosts, and that some generators add unique value. The validation pipeline is careful, including bloom-filter dedup and aliasing checks. Credit where due: this is a well-executed measurement study.\n\nThe soft spots are real but not fatal. The central practical claim—that 6Scan and 6Graph on DNS (www) plus all hitlists cover 95% of deployments—is computed on the same data used to pick those two generators. That is selection on the outcome. The paper even acknowledges in Section VI that it cannot estimate what fraction of all IPv6 installations it covered. So the 95% is an in-sample score, not a validated recipe for future scans. A temporal holdout, running the chosen generators on a later scan, would make the claim credible. If the authors can't do that, they should soften the language.\n\nTwo other issues. First, the security numbers are descriptive and lack error bars or controls; the paper notes the cloud-provider bias in its own Section V. Second, there's an internal inconsistency: the abstract says only 39% of deployments have access control, while the conclusion says 39% fail to implement it. Those are opposite claims. That needs fixing.\n\nAlso worth noting: 6,650 of the 6,658 deployments are backend services; only 8 are devices. The title says 'IoT Deployments,' which is acceptable, but readers should not mistake this for a census of IPv6 devices. And the underlying deployment list is not released, only the tools, so exact replication is limited.\n\nWho is this for? Researchers planning IPv6 scans for non-web services. The methodology is reusable, and the source-tracking approach is worth copying. I'd like to see this in the literature after a revision that addresses the post-hoc claim and the access-control discrepancy. It deserves a serious referee.","headline":"First systematic IPv6 IoT discovery study, with a post-hoc generator-coverage claim that needs external validation before it becomes a recipe.","tokens_in":15531,"tokens_out":3244,"would_cite":true,"duration_ms":27656,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"IPv6-reachable IoT deployments can be found efficiently, and they are about as insecure as IPv4 ones.","keywords":["IPv6 address space","Internet-wide scanning","IoT discovery","address generators","hitlists","MQTT","AMQP","IoT security"],"falsifier":"Deploy a set of IoT test services at freshly allocated IPv6 addresses drawn from sources outside the three seedlists (for example, brand-new ISP prefixes or addresses from public NTP pools), then run the paper's recommended pipeline; if the pipeline finds far fewer than 95% of these known deployments, or if a full eleven-generator run finds many deployments the subset misses on a later scan date, the central coverage claim is refuted.","tokens_in":14654,"feed_emoji":"📡","tokens_out":5608,"duration_ms":49573,"temperature":0.7,"pith_summary":"The paper claims that IPv6-reachable IoT deployments can be discovered efficiently enough to bring them into Internet-wide security studies, despite the impossibility of scanning the full IPv6 address space. Combining three sources of known-active IPv6 addresses (the TUM hitlist, DNS AAAA records, and addresses derived from IPv4 scans) with eleven public address generators, the authors found 6,658 live AMQP, MQTT, OPC UA, and CoAP deployments. By tracing which addresses each source and generator contributed, they conclude that most generators are redundant: two generators, 6Scan and 6Graph, seeded on the DNS-with-www list, plus the available hitlists, recover 95% of all found deployments at a fraction of the cost. They further report that these IPv6 deployments are about as insecure as their IPv4 counterparts, with only 6.2% using TLS and 39% missing access control, even though IPv6 deployments look newer. A sympathetic reader would take this as evidence that IPv6 IoT is now reachable for empirical study and that security assessments ignoring IPv6 are incomplete.","feed_headline":"Two generators find 95% of IPv6 IoT deployments","feed_subtitle":"A 14-billion-address scan found 6,658 deployments; security flaws match IPv4.","key_machinery":"The load-bearing machinery is the combination of seedlists and IPv6 address generators, with per-address origin tracking to attribute every found deployment to its source. Seedlists (the TUM hitlist, DNS AAAA records from ICANN zone files, and reverse-DNS/certificate data from a prior IPv4 scan) provide real, currently used addresses; generators such as 6Scan (which uses regional encoding and active probing to propose new search directions) and 6Graph (which mines address patterns as high-density regions in a graph) expand from those seeds into unlisted addresses. Origin tracking is what lets the paper rank generators and claim that two generators plus all hitlists recover 95% of deployments, since without it the overlap between generator outputs is invisible.","core_discovery":"The central claim is that a practical recipe exists for discovering IoT deployments in the IPv6 Internet, and that applying it reveals a security situation as bad as IPv4's. The authors scanned roughly 14 billion IPv6 addresses generated from three seed sources and eleven generators, validated responders at the application layer, and identified 6,658 IoT deployments: 6,650 backend services (AMQP, MQTT) and only 8 device-side services (OPC UA, CoAP). Source tracing shows the TUM seedlist supplies the most deployments, the openly filtered version of that list is unsuitable because Web/ICMP liveness filtering removes IoT addresses, and generator output adds 768 deployments beyond the seedlists. The efficiency claim is that 6Scan and 6Graph on DNS (www) plus all available hitlists cover 95% of the found deployments, so future studies can skip the remaining generators. Security-wise, the paper claims IPv6 deployments mirror IPv4: 6.2% versus 6.3% use (D)TLS, 39% versus 48% lack access control, and IPv6 deployments are more likely to accept deprecated ciphers and short RSA keys, despite a larger share supporting TLS 1.3 (63% versus 35%).","pith_inferences":["The paper does not test this, but if the 95% coverage result reflects IPv6 address structure rather than IoT-specific quirks, the same two-generator-plus-hitlists recipe may also improve IPv6 discovery for other non-Web services beyond IoT, such as industrial protocols or email servers.","Because the found IPv6 deployments skew toward content and cloud networks, the security fractions may understate the risk in home or ISP-run deployments, which the paper notes could bias results; an IPv6 scan starting from ISP-heavy seedlists would test this.","The paper does not claim this, but the coverage result is relative to the 6,658 deployments this pipeline found, not to the unknown total IPv6 IoT population; if systematically missed deployments differ in security, the headline 39% and 6.2% numbers could shift.","A direct extension would be to run the recommended subset and the full pipeline side by side on a fresh date and measure overlap, turning the 95% statement into a reproducible benchmark for future scan-strategy papers."],"forward_implications":["Future IPv6 IoT studies can run the TUM unfiltered list, DNS (www) seeds, and the v4-derived list through 6Scan and 6Graph and expect to see about 95% of the deployments a full eleven-generator pipeline would find, with far less compute.","Internet-wide security assessments that stop at IPv4 miss a population of deployments, including 89 deployments in ASes with no IPv4 findings.","IPv6 deployments are newer but not better secured, so IPv6-specific hardening and monitoring are needed, not just a hope that modern stacks fix legacy mistakes.","Researchers should not rely on the openly filtered TUM hitlist for IoT scanning, because its Web/ICMP reachability filter removes addresses that still run IoT services.","The four-protocol finding that only 6.2% use TLS and 39% lack access control gives a baseline for measuring future IPv6 IoT security."],"supporting_citations":[{"why":"Supplies the TUM hitlist, the main seed source and the basis for the open unfiltered-versus-filtered comparison.","marker":"[11]"},{"why":"Documents the extended TUM hitlist and its reduced effectiveness for Web services, motivating the paper's seedlist analysis.","marker":"[12]"},{"why":"Defines 6Graph, one of the two generators whose output underpins the 95% coverage claim.","marker":"[13]"},{"why":"Defines 6Scan, the high-hitrate active generator that drives the 95% coverage claim.","marker":"[15]"},{"why":"Evaluates IPv6 target generation algorithms and informs the selection and seeding of generators.","marker":"[16]"},{"why":"Prior hitlist-only IoT backend study whose low yield establishes the baseline the paper improves on.","marker":"[17]"},{"why":"Prior IPv6 IoT host analysis using only a hitlist, providing the comparison point for generator gains.","marker":"[18]"},{"why":"Supplies the IPv4 IoT security assessment method and the comparison numbers for TLS and access control.","marker":"[19]"},{"why":"Provides IPv4 MQTT and AMQP insecure-deployment findings used for the IPv4-versus-IPv6 security comparison.","marker":"[20]"},{"why":"The ICANN Centralized Zone Data Service is the source of DNS AAAA seedlist entries used in the scans.","marker":"[62]"}],"fun_headline_variants":["14B IPv6 scan finds 6,658 IoT deployments","IPv6 IoT: only 6% use TLS, 39% lack access control","Two generators cover 95% of IPv6 IoT deployments","IPv6 IoT security: mirrors IPv4 flaws in 6,658 devices"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing assumption is that the 6,658 discovered deployments represent all IPv6-reachable IoT deployments, so the coverage percentages and security figures generalize; the paper itself concedes it cannot reliably estimate what portion of installations it covered and that the cloud-provider focus may bias the security results.","fun_headline_variants_meta":{"raw":{"variants":["14B IPv6 scan finds 6,658 IoT deployments","IPv6 IoT: only 6% use TLS, 39% lack access control","Two generators cover 95% of IPv6 IoT deployments","IPv6 IoT security: mirrors IPv4 flaws in 6,658 devices"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000949,"raw_usage":{"total_tokens":4102,"prompt_tokens":1047,"completion_tokens":3055,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":663,"completion_tokens_details":{"reasoning_tokens":2989}},"tokens_in":663,"tokens_out":3055,"duration_ms":19410,"temperature":1.0,"reasoning_tokens":2989,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T15:51:10.639741+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Deploy a set of IoT test services at freshly allocated IPv6 addresses drawn from sources outside the three seedlists (for example, brand-new ISP prefixes or addresses from public NTP pools), then run the paper's recommended pipeline; if the pipeline finds far fewer than 95% of these known deployments, or if a full eleven-generator run finds many deployments the subset misses on a later scan date, the central coverage claim is refuted.","supporting_citations":[{"cited_title":"Clusters in the Expanse: Un- derstanding and Unbiasing IPv6 Hitlists,","cited_arxiv_id":null,"evidence_quote":"Supplies the TUM hitlist, the main seed source and the basis for the open unfiltered-versus-filtered comparison."},{"cited_title":"Rusty Clusters? Dusting an IPv6 Research Foundation,","cited_arxiv_id":null,"evidence_quote":"Documents the extended TUM hitlist and its reduced effectiveness for Web services, motivating the paper's seedlist analysis."},{"cited_title":"6Graph: A graph-theoretic approach to address pattern mining for Internet-wide IPv6 scanning,","cited_arxiv_id":null,"evidence_quote":"Defines 6Graph, one of the two generators whose output underpins the 95% coverage claim."},{"cited_title":"6Scan: A High- Efficiency Dynamic Internet-Wide IPv6 Scanner With Regional Encod- ing,","cited_arxiv_id":null,"evidence_quote":"Defines 6Scan, the high-hitrate active generator that drives the 95% coverage claim."},{"cited_title":"Target Acquired? Evaluating Target Generation Algorithms for IPv6,","cited_arxiv_id":null,"evidence_quote":"Evaluates IPv6 target generation algorithms and informs the selection and seeding of generators."},{"cited_title":"Deep Dive into the IoT Backend Ecosystem,","cited_arxiv_id":null,"evidence_quote":"Prior hitlist-only IoT backend study whose low yield establishes the baseline the paper improves on."},{"cited_title":"Analyzing IoT Hosts in the IPv6 Internet","cited_arxiv_id":"2307.09918","evidence_quote":"Prior IPv6 IoT host analysis using only a hitlist, providing the comparison point for generator gains."},{"cited_title":"Missed Opportunities: Measuring the Untapped TLS Support in the Industrial Internet of Things,","cited_arxiv_id":null,"evidence_quote":"Supplies the IPv4 IoT security assessment method and the comparison numbers for TLS and access control."},{"cited_title":"Open for Hire: Attack Trends and Misconfiguration Pitfalls of IoT Devices,","cited_arxiv_id":null,"evidence_quote":"Provides IPv4 MQTT and AMQP insecure-deployment findings used for the IPv4-versus-IPv6 security comparison."},{"cited_title":"Centralized Zone Data Service,","cited_arxiv_id":null,"evidence_quote":"The ICANN Centralized Zone Data Service is the source of DNS AAAA seedlist entries used in the scans."}],"review_version":1}