IPv6 Proactive Telescope

• IPv6 proactive telescope is a purpose-built infrastructure that intentionally attracts and analyzes unsolicited IPv6 scan traffic using controlled BGP announcements, DNS records, and hitlist inclusion.
• It employs responsive honeypots and periodic BGP reconfigurations to modulate its visibility and capture diverse scanning behaviors from research, commercial, and adversarial sources.
• Quantitative studies show that proactive signaling boosts scan traffic by up to 286% and enhances ASN diversity, informing security research and network defense strategies.

An IPv6 Proactive Telescope is a purpose-built observational infrastructure—often comprising instrumented address blocks, responsive honeypots, and systematic public signaling—designed to attract, record, and analyze unsolicited IPv6 scan and probe traffic. Its function is to illuminate scanning dynamics, evaluate proactive and passive measurement strategies, and infer adversarial and research-driven scanner behaviors across the IPv6 Internet. Unlike passive “darknets,” the proactive telescope can directly control and instrument its visibility by leveraging BGP announcements, DNS zone deployments, TLS certificates, and hitlist insertions, thereby intentionally altering its footprint in the global IPv6 address space and modulating scanner response for paper (Tanveer et al., 10 Aug 2025, Egloff et al., 25 Jun 2025).

1. Telescope Design, Activation, and Signaling Strategies

An IPv6 proactive telescope requires the selection and activation of significant portions of routable IPv6 address space (e.g., an ISP’s /32). These resources are carved into independently manageable subnets—typically /48 “honeyprefixes”—whose visibility to the global Internet is governed by proactive signaling methods:

• BGP Announcements: Individually announcing formerly dark or dormant prefixes in the global routing table rapidly attracts scanner attention. Controlled splitting and timed re-announcements (e.g., subdividing a /32 into new /48s every two weeks) trigger bursts of scanner probing, as evidenced by packet volume increases up to +286% following new announcements (Egloff et al., 25 Jun 2025).
• DNS and Domain Names: Publishing AAAA records for created domains (and subdomains), especially those validated via DNS-01 challenges for TLS certificate generation, exposes addresses to scanners monitoring DNS and certificate transparency logs.
• Hitlist Inclusion: Submission of addresses to public or well-trafficked IPv6 hitlists further advertises the telescope’s existence to scanners using hybrid or hitlist-based target selection techniques (Gasser et al., 2016).
• Responsive Honeypots: Deploying IP aliasing honeypots (e.g., Twinklenet) and high-interaction honeypots (e.g., T-Pot) provides multi-protocol responsiveness, further enticing and facilitating richer scanner interactions.

Each signaling mechanism can be experimentally toggled per honeyprefix to isolate its effect on scan attraction, diversity of sources, and resultant traffic composition (Tanveer et al., 10 Aug 2025).

2. Traffic Collection, Attribution, and Analysis

The telescope collects unsolicited IPv6 probe traffic over extended periods (e.g., 10 months), yielding datasets of scale—on the order of 600 million packets from 1,900 ASNs (Tanveer et al., 10 Aug 2025). The capture infrastructure logs packet headers and payloads for all incoming protocols (ICMPv6, TCP/UDP, etc.) and statistically differentiates scanner behaviors by traffic type, volume, timing, and source diversity.

Key techniques include:

• Address Aggregation: Group packet sources at varying prefix granularities (/128 for unique hosts, /64 for source aggregation, /32 for network view) to distinguish behavioral patterns (e.g., address rotation within /64 by research probes).
• Autonomous System (AS) Analysis: Attribute sources using AS lookups to classify scanners as cloud providers, research organizations, or commercial/malicious actors.
• Jaccard Similarity Analysis: Compute overlap of scanner sources observed at multiple data collection points using $$JS(NT_y, NT_x) = \frac{|Sources_{agg}(NT_y) \cap Sources_{agg}(NT_x)|}{|Sources_{agg}(NT_y) \cup Sources_{agg}(NT_x)|}$$ to reveal the extent of scanner reach and adaptation (Tanveer et al., 10 Aug 2025).

A significant share of scanner traffic is ICMP-based, especially from cloud and hosting providers. Specialized Internet Scanner ASNs may prefer TCP probes, while address block size and scanning patterns (e.g., covering /30s versus /96s) vary with scanner type.

3. Scanner Behavior and Adaptation to BGP Signals

Scanners adapt quickly and exhibit pronounced sensitivity to BGP signals:

• BGP Reactivity: The announcement of new prefixes is immediately followed by increased scan volumes and greater scanner diversity. Controlled BGP experiments confirm that formerly invisible (silent) subnets in larger address blocks become “magnets” for scanning upon individual announcement (Egloff et al., 25 Jun 2025). The probability of scanner contact can be modeled as $P_{scan}(t) \propto e^{\alpha \cdot \Delta BGP(t)}$, with ΔBGP(t) denoting a change in prefix announcement.
• Temporal Patterns: Scanner behaviors are categorized as one-off (single session), periodic (regular intervals, often research/measurement infrastructure), or intermittent (irregular timing). Periodicity is often detected via autocorrelation.
• Target Generation Strategies: Scanners select probe targets either by exploiting common address structure (e.g., low-byte addresses = ::1), performing block sweeps, or introducing randomness in the IID portion. Structured scans are evident in deterministic subnet sweeps; randomized IIDs have been statistically confirmed using NIST suite frequency and runs tests, with p-values (e.g., p ≥ 0.01) used to distinguish randomness.
• Tool Fingerprinting: Payload analysis employing DBSCAN clustering on packet contents, combined with reverse DNS of sources, identifies tools like RIPE Atlas probes, Yarrp6, Htrace6, and also uncovers persistent campaigns by commercial actors (e.g., Alpha Strike Labs).

4. Feature Evaluation and Quantitative Impact

Through controlled experimental design, the relative impact of different proactive features is measured using Bayesian Structural Time-Series Models, which compare the treatment (signaled honeyprefix) versus control (unconfigured) subnets.

Key metrics:

• Δ_H^traffic: Average daily increase in scan packet volume induced by features.
• Δ_H^ASN: Average daily increase in source ASN diversity.
• Jaccard Similarity: Quantifies overlap in observed scanning sources between telescope deployments, illustrating moderate shared coverage (JS ≈ 0.1–0.2).

Findings indicate that BGP-only announcement is the strongest standalone signal for attracting scanners, but combining DNS naming, TLS certificates, and hitlist inclusion further increases capture rates and source diversity. IP aliasing and protocol responsiveness, while less significant alone, can stimulate additional multi-protocol scanning from sophisticated actors (Tanveer et al., 10 Aug 2025).

5. Operational Guidance and Telescope Configuration

Empirical observations yield concrete recommendations for telescope operators:

Guidance	Rationale	Source
Announce individual prefixes via BGP	Rapidly increases scanner contact and session volume, making the telescope more visible.	(Egloff et al., 25 Jun 2025)
Periodically reconfigure BGP announcements	Enables calibration of scanner reactivity and sensitivity, and causes repeat visitation.	(Egloff et al., 25 Jun 2025)
Incorporate multiple attractors (DNS, TLS)	Reaches scanners that monitor various public datasets, covering a wider range of adversaries and research campaigns.	(Tanveer et al., 10 Aug 2025)
Monitor at multiple aggregation levels	Compensates for scanner use of address rotation, especially within /64 blocks.	(Egloff et al., 25 Jun 2025)
Avoid relying solely on public hitlists	BGP activation trumps hitlist inclusion for attracting scanning traffic.	(Egloff et al., 25 Jun 2025)

A plausible implication is that maintaining only a silent subnet within a larger announced prefix (i.e., not individually announcing it in BGP) will result in near-zero unsolicited traffic visibility.

6. Implications and Future Directions

The integration and synchronization of proactive features (BGP, DNS, TLS, honeypots, and hitlist management) not only enhance scan traffic capture rates but also provide operational levers to paper scanner behaviors under realistic Internet conditions. The approach enables the repurposing of proactive telescopes for evaluating the effectiveness of IPv6 blocklisting, informing intrusion detection policies, and advancing the broader understanding of adversarial reconnaissance tactics.

Future opportunities include:

• More granular signal experimentation to decipher the weight scanners assign to various public signals (e.g., determining scanner dependence on DNS records versus BGP visibility).
• Detailed mapping of the interplay between public datasets and scanner target selection strategies.
• Expansion of active interaction capabilities to better emulate and paper the targeting of production IPv6 services by sophisticated adversaries (Tanveer et al., 10 Aug 2025).

7. Summary

An IPv6 proactive telescope operationalizes the concept of intentional, flexible observability at scale within the IPv6 Internet. Through judicious network activation, multi-protocol responsiveness, and targeted outreach via BGP, DNS, and public records, the proactive telescope compels scanner activity that can be systematically captured, classified, and utilized for security research and operational defense. Empirical studies demonstrate—via large-scale ISP deployments—that such telescopes dramatically increase unsolicited scan capture rates, uncover diverse scanning strategies, and provide a robust foundation for advanced measurement and cyber defense in the IPv6 era (Tanveer et al., 10 Aug 2025, Egloff et al., 25 Jun 2025).