IPv6 Hitlist Service: Lessons Learned From 10 Years of Operation

1 Introduction

• IPv6’s address space is 10^29 times larger than IPv4’s, making exhaustive IPv6 scanning infeasible and motivating hitlists and other smart target-selection approaches.The introduction contrasts IPv4 brute-force scans, which can cover the complete address space within hours, with IPv6.Source: §1 · p. 1
• Created in 2016, the IPv6 Hitlist Service grew to 60× its initial total addresses and 10× its initial responsive addresses.The service progressed from an internal, request-based hitlist to a publicly usable service in 2018.Source: §1 · p. 1
• The paper assesses hitlist coverage against real-world traffic, reporting at least one known address for 87 % of ASes and 56 % of IPv6-originating /48 prefixes.The traffic data came from a major central European ISP and a Tier-1 network.Source: §1 · p. 1
• The paper also reports a user survey, analyzes access patterns, and offers best-practice recommendations and lessons from the service’s operation.The described access patterns include daily versus one-off access and downloads of all versus responsive addresses.Source: §1 · p. 2

2 Technical Development

• The pipeline combines address sources, removes duplicates to produce 5.24 B input addresses, then applies blocklist and routable-prefix filters that remove 81 M addresses.The blocklist filter enforces opt-out mechanisms for ethical scanning.Source: §2 · p. 2
• Aliased Prefix Detection removes 678 M addresses, and a filter for addresses unresponsive for over 30 days removes 4.02 B, leaving 458 M to scan.For eligible subnets, the method probes 16 addresses and labels a subnet aliased when all respond in the current or previous two scans.Source: §2 · p. 2
• The service randomizes addresses, runs traceroute and multiple ICMP, TCP, and UDP probes, and publishes addresses responsive to at least one protocol.Exact results by probe are available in the registration-first section; responsive addresses are published without registration.Source: §2 · p. 2
• Pipeline updates included MPTCP and SNMPv3 probes, filtering DNS injections attributed to the Great Firewall of China, and later DNS and runtime optimizations.The DNS filter improved scan-result quality and reduced subsequent scan runtime; later optimizations were implemented between November 2024 and April 2025.Source: §2 · p. 2
• Including TGA-generated addresses in 2022 increased responsive addresses by 173 %; from November 2023, IPinfo datasets increased input addresses and scanning runtime, mainly because APD scans each included /64 prefix.Source: §2 · p. 3
• Trend analysis linked a late-2019 responsiveness drop across ASes and protocols to a hardware fault, and mid-2024 declines to short-lived IPinfo addresses no longer being replenished after source removal.The IPinfo addresses often became unresponsive after a few scans and were replaced by other responsive addresses; some later drops coincided with provider address or prefix rotations.Source: §2 · p. 3, Figure 2 · p. 3

3 IPv6 Hitlist Coverage

• The study compares hitlist coverage with sampled flow data aggregated hourly by source /48 prefix, which contains no flow-target information.The comparison therefore measures whether known hitlist addresses map to traffic-originating ASes and prefixes, rather than whether they were traffic destinations.Source: §3 · pp. 3–4
• 87.1% of observed ASes, 56.5% of /48 prefixes, and 97.2% of captured traffic had at least one address known to the hitlist.The comparison uses April 30, 2026 hitlist data and three months of flow data.Source: Table 3 · p. 4, §3 · p. 4
• The flow dataset covered three months and contained 24.1 k source ASes and 6.9 M /48 prefixes; 10 ASes accounted for 54.7% of prefixes.A majority of prefixes appeared on only 1–2 days, potentially reflecting rotating prefix assignments.Source: §3 · p. 4
• 54.7% of captured traffic came from /48 prefixes with a responsive hitlist address, although these represented only 8.8% of prefixes.Responsive addresses were present in 74.8% of observed ASes; UDP/443-responsive addresses covered the fewest ASes and prefixes while covering 32.1% of traffic.Source: §3 · p. 4
• 51.4% of traffic came from aliased prefixes, which appeared in 2.8% of traffic-visible ASes and 0.5% of prefixes.Aliased prefixes and responsive addresses together covered 95.3% of traffic; the authors recommend sampling addresses from aliased prefixes for scans.Source: §3 · p. 4
• Toplist-resolved addresses mapped to 30.5 k /48 prefixes that originated 88.8% of traffic, but covered fewer prefixes and ASes than the hitlist.The comparison used AAAA records from four domain toplists over 1, 7, and 30 days; relying only on toplist DNS resolution misses the long tail of ASes.Source: §3 · p. 4

4 User Survey

• 22 of 32 IPv6 measurement respondents used the hitlist, while 9 did not and 1 might use it in the future.Nonusers cited lack of awareness or a mismatch with their needs.Source: §4 · p. 5
• Respondents used varied address sources: 17 had their own collections, 10 used TGAs, and 6 used a similar service.Using the hitlist alone or with a personal collection were the two most common combinations.Source: §4 · p. 5
• 11 respondents used both publicly available and registration-first data, while 5 used only public data and 4 only registration-first data.Among 15 registration-first data users, the combinations of responsive, all-address, and aliased-prefix data varied.Source: §4 · p. 5
• The most commonly reported tools were ZMapv6 (13 respondents) and ZGrab2 (9); servers and routers were each targeted by 12 respondents.Nine respondents reported targeting clients; respondents could select multiple device types and tools.Source: §4 · p. 5
• 14 respondents said their hitlist-based research produced publications, and all 20 who answered the importance question rated the service important or very important.Nineteen of 20 respondents supported continuing the service; 9 said it was very important to their research.Source: §4 · p. 5
• Respondents proposed an API, responsiveness information over time, and hitlist subsets for categories such as routers, servers, and CDNs.The survey received 33 responses over 30 days, from February 18 to March 20, 2026.Source: §4 · pp. 4, 6

5 IPv6 Hitlist Use

• During data collection, 17 users and 2 measurement services accessed registration-first results; response files were most commonly accessed (15×), followed by aliased prefixes (9×) and input files (8×).Source: §5 · p. 6
• Registered users ranged from one-day access to weekly downloads, and one user downloaded historical aliased-prefix data dating to 2018 within three days.The authors interpret varied data granularity and download timing as signs of focused use, including to reduce follow-up scan scale.Source: §5 · p. 6
• 8 public-data entities accessed the service daily throughout the 120-day period, while 609 of 653 AS-user-agent pairs accessed on 5 days or fewer.AS and user-agent pairs were used because public-data access lacked registration information; they do not necessarily identify individual research entities.Source: §5 · p. 6

6 Best Practices & Lessons Learned

• Responsive-address lists contain hosts with positive ICMP Echo, TCP SYN/ACK, or valid UDP responses, but include few routers and clients and focus on DNS and web protocols.The authors recommend using cumulative input for follow-up service scans.Source: §6 · p. 6
• Aliased prefixes should neither be ignored nor removed wholesale: they can skew address-based results, yet may represent fully responsive load-balanced CDN space.The authors recommend sampling addresses from aliased prefixes and checking for additional aliases when adding sources or using addresses such as TGA outputs.Source: §6 · p. 6

A Hitlist Pipeline

• The service pipeline is summarized as collecting input sources, applying filters, and conducting scans.The passage points to earlier work and the paper’s pipeline discussion for design and change details.Source: A Hitlist Pipeline · p. 8

B Survey Details

• The survey ran for 30 days and received 33 responses; question variants and response annotations were used for conditional, multiple-choice, optional, and free-text items.The period was February 18–March 20, 2026.Source: B Survey Details · p. 8

B.1 Are you performing IPv6 measurements?

• The questionnaire asked whether respondents currently performed, had previously performed, or planned IPv6 measurements, and included options for other address sources such as personal collections and TGAs.Other options included a similar target-list service, higher-layer measurement without dedicated targets, and undecided or no additional source.Source: §B.1 · p. 8, §B.3 · p. 8

• Duration choices included one-off downloads and a total period of 1 month.Source: §B.6 · p. 8
• Respondents could select a download period of 2–6 months.Source: §B.6 · p. 8
• Longer options were 7–12 months and more than 12 months.Source: §B.6 · p. 8

• Respondents could report downloading new data daily or weekly.Source: §B.7 · p. 8
• Monthly downloads were another frequency option.Source: §B.7 · p. 8
• The remaining choices were less frequently than monthly or one-off downloads.Source: §B.7 · p. 8

• One response option was publicly available data.Source: §B.9 · p. 8
• A second option was data available after registration.Source: §B.9 · p. 8
• The question framed access as a choice between public and registration-based availability.Source: §B.9 · p. 8

B.10 Multi: Which data do/did you download from the IPv6 Hitlist Service?

• Users could identify downloads of all collected addresses (“input”), responsive addresses (“output”), aliased prefixes, or non-aliased prefixes.Source: §B.10 · p. 9

B.11 Multi: How do you filter aliased/highly-responsive prefixes from your IPv6 measurements?

• For filtering aliased or highly responsive prefixes, options included using the service’s lists, running detection measurements, or not filtering them out.Source: §B.11 · p. 9

B.12 Multi: Which tool(s) do/did you use to run your IPv6 measurements?

• The survey listed ZMapv6, ZGrab2, yarrp6, nmap, traceroute, scamper, and other tools as measurement options.Source: §B.12 · p. 9

B.13 Which types of devices are you targeting in your IPv6 measurements?

• Respondents could say whether they targeted routers, servers, clients, or other device types.Source: §B.13 · p. 9

B.14 Did the measurements where you used the IPv6 Hitlist Service result in a peer-reviewed publication?

• Publication options ranged from having a peer-reviewed publication to having no publication planned.Source: §B.14 · p. 9

B.15 How important is/was data from the IPv6 Hitlist Service for your research?

• The survey asked whether service data was indispensable, important for parts of the research, or not important.Source: §B.15 · p. 9

B.16 Should we continue to take efforts to keep the IPv6 Hitlist Service running?

• Users could indicate whether the service should continue, was merely neutral to have, or was no longer needed.Source: §B.16 · p. 9
• A separate question asked whether users would share addresses or measurement data, with yes, maybe, and no options.Source: §B.16 · p. 9