APNIC Pty Ltd.

06/11/2026 | Press release | Distributed by Public on 06/10/2026 23:20

Discovery of IPv6 router addresses using Subnet-Router Anycast addresses

Identifying active IPv6 addresses is a challenging task, but it's also an important one. As researchers and network operators, it helps us understand the current deployment, identify weak spots that need strengthening, and detect vulnerable devices for disclosure.

A major challenge is selecting the right target addresses for probing. Brute-force scans are infeasible due to the vast number of IPv6 addresses. What's more, topology measurements based on traceroute are constrained by ICMPv6 error message rate limiting, making high-speed probing difficult.

To fix this problem, we update the IPv6 measurement toolbox with Subnet-Router Anycast (SRA) probing - an approach that drops the need for prior knowledge of address allocation in active networks and is significantly less affected by ICMPv6 error message rate limiting. This provides more stable measurement results than random probing and allows for higher probing rates.

What are SRA addresses, and how do they work?

SRA addresses were introduced to the IPv6 addressing architecture (RFC 1884) as a way to enable applications to communicate with a router of the subnet, without knowing the actual IPv6 router address. Since then, few use cases for SRA addresses have been found.

Syntactically, SRA addresses are unicast addresses. They represent the subnet, in that the host part of the IPv6 address is set to 0. For example, for the subnet the SRA address is . Each router is required to support an SRA address if it has an interface to this subnet. Routers receiving a packet targeting an SRA address of one of its subnets should reply with their own full source address.

For example, a router:

  • With the two interfaces and
  • That receives a packet to via its interface
  • Will reply with the source address .

Notably, implementations differ in their behaviour.

SRA addresses and IPv6 address space probing

To successfully deploy our probing, we needed to partition the IPv6 address space such that each partition represented an active subnet. Let's take a look at how we used SRA addresses to explore new active subnets and new IPv6 router addresses.

Partitioning the IPv6 address space announced in BGP to create SRA addresses

At the time of writing, approximately 200k IPv6 prefixes are announced in BGP.

Probing the SRA address of each routable prefix as it was announced in BGP missed internal, more specific subnets. To balance scan traffic and increase the chance of discovering new addresses, we partitioned the routable address space into three stages. We employed this multi-stage approach to determine which input set was most suitable for SRA probing.

Figure 2 shows an example address for each stage given the input prefix .

  1. We started by querying the SRA address of each announced prefix. All bits of the given input prefix were left unchanged in target generation.
  2. Then, we partitioned the routable address space into /48 subnets and scanned the SRA address of each subnet by creating all bit combinations of the first n-bit block that followed the original subnet prefix, where n=48-[prefix length]. This step resulted in 15 billion potential targets.
  3. Finally, we partitioned all /48 announcements in BGP (around 100k) further into /64 subnets. We created all bit combinations of the first 16-bit block that followed the original subnet prefix

Creating SRA addresses using other input sources

BGP announcements reflected intended reachability. There were, however, other sources containing more specific subnet assignments, which could be used to increase the effectiveness of our method. In addition to BGP announcements, we considered two input sources to create SRA addresses.

First, we collected route(6) objects from IRR databases, which predominantly contained /48 prefixes. For each of the nearly 1M prefixes, we created up to 10k random /64 SRA addresses, adding up to 10B targets.

Second, we constructed a target set from the TU Munich Hitlist (2.5B addresses) by taking the first 64 bits of each host address and setting the remaining 64 bits to zero, which resulted in 700M distinct targets.

Response rates among different input sources

We observed widely varying response rates per scan, ranging from 3.2% up to 20%. The ratio between newly discovered routers and probed IP addresses strongly depended on the input source (see Table 1). Importantly, these differences reflected two factors:

  • How deeply we probed into subnets (for example, probing /64s).
  • Whether the probed address space was known to be active.

Probing more deeply into subnets (/64)

Generating more specific subnets based on BGP or route(6) input data usually led to subnets that were not assigned to any router interface, triggering many ICMP error messages when probed. As a result, the discovery rate remained below 1% for most scans, although the unmodified BGP prefix scan showed a somewhat higher reply rate in relative terms. With only 28k IPv6 router addresses discovered and an overlap of greater than 90% with the other scans, the effect of probing these more specific, artificially generated subnets was negligible.

However, exploring announced BGP prefixes in more depth by probing the SRA address of all /64 subnets of the announced /48 prefixes revealed 45M IPv6 router addresses. Although the number of subnets to probe was high, the method did not require prior knowledge of the active address space, making it a valuable input set for SRA probing.

Probing address space that is known to be active (hitlists, unique /64s)

In contrast, the /64 subnets resulting from the TU Munich Hitlist were not artificially generated but cut off from the host address of an (at least at some point in the past) active host. Therefore, it was much more likely that the probed subnet was active and assigned to a periphery router, which did not return an error message but instead responded with an ICMPv6 Echo reply. Consequently, when using the full TU Munich Hitlist (unique /64s), 72M unique IPv6 router addresses could be discovered by sending only 700M requests, yielding a discovery rate exceeding 10%.

Input for probing Results
Source Number of subnets Subnet size Number of probed addresses Number of replies Number of IPv6 router addres
BGP (all) 200k As announced 200k 38k (19%) 28k (14%)
BGP (all) 200k /48 11B 50M (3.2%) 4M (0.04%)
route(6) (all) 1M /64 10B 570M (5.7%) 14M (0.14%)
BGP (/48) 100k /64 6.5B 1.3B (20%) 45M (0.69%)
Hitlist (unique /64s) 700M /64 700M 90M (13%) 72M (10.3%)
Total 28.2B 2.32B 135M
(Distinct 133M)

Table 1 - Comparison of different input sets to probe Subnet-Router anycast addresses and their effectiveness for SRA probing. The hitlist input reveals the most router IP addresses while probing only 700M SRA addresses.

SRA probing avoids ICMP errors when re-probing active subnets

SRA probing was most effective when re-probing active subnets.

The chance of hitting an active device at all using a random IPv6 address is almost zero.

Random probing triggered ICMP messages when previously responsive addresses later became unreachable, and excessive errors were eventually suppressed.

Sending probes to an enabled SRA address triggered an ICMP message, independently of whether the IPv6 router address changed or not, and avoided common ICMP error message rate limiting.

Figure 3 shows the total number of discovered IPv6 router addresses based on SRA and random probing for a measurement series using the TU Munich Hitlist /64 subnets. Per scan campaign, we found about 10% more IPv6 router addresses with SRA probing. The number of IPv6 router addresses that responded with an Echo Reply message remained stable, which clearly showed that our SRA scans were far less affected by ICMP rate limiting. We also found around 9M IPv6 router addresses exclusively with SRA probing.

Comparing SRA probing with other public datasets

We compared our measurement results with multiple datasets of different characteristics. These datasets were publicly available IPv6 traceroute measurements, and a popular public hitlist of active hosts.

We observed little overlap in terms of IPv6 addresses (< 5%). Each datasource represented a unique view of the IPv6 address space.

Considering all Autonomous System Numbers (ASNs), however, showed that more than 99% of the ASNs found through SRA probing were also present in the other datasets. This indicated that the number of discovered router addresses was not an artifact of probing unexplored networks but a result of the probing technique itself.

In a nutshell

SRA probing is an important addition to the IPv6 measurement toolbox, serves as a complementary source for IPv6 router addresses, and may improve the stability of results significantly.

Rate limiting was a key reason for the instability of detected IPv6 addresses. We showed that probing the SRA address of a target subnet provided more stable results than random probing, because SRA probing circumvented the rate limiting of ICMPv6 error messages.

Weekly SRA measurements

We provide a weekly updated dataset of IPv6 router addresses. This data set includes the replying router address and whether the router would reply when targeted directly.

More details are available in our article 'Scanning the IPv6 Internet Using Subnet-Router Anycast Probing ' presented at ACM CoNEXT 2025 and published in the Proceedings of the ACM on Networking.

Maynard Koch is a PhD student and research associate at the Chair of Distributed and Networked Systems at TU Dresden, supervised by Prof. Dr Matthias Wählisch. Before joining TU Dresden, he graduated with a BSc and MSc in Computer Science from Freie Universität Berlin. His research focuses on Internet measurements to improve network security. He is particularly interested in DNS and scalable IPv6 scanning.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

APNIC Pty Ltd. published this content on June 11, 2026, and is solely responsible for the information contained herein. Distributed via Public Technologies (PUBT), unedited and unaltered, on June 11, 2026 at 05:20 UTC. If you believe the information included in the content is inaccurate or outdated and requires editing or removal, please contact us at [email protected]