Subnet-Router Anycast Probing: A Map That Isn't a Census
On its face this is a paper about a faster way to ping IPv6 routers, which sounds like the kind of measurement-lab housekeeping that never leaves the lab. It looks routine. It isn't. What Maynard Koch's June 2026 work on the APNIC blog actually does is hand anyone who manages address space a cleaner instrument for seeing the routing fabric, while quietly exposing how often that instrument gets misread the moment a big number comes out of it.
Koch's method, Subnet-Router Anycast (SRA) probing, is a quietly clever reuse of a 1990s addressing feature almost nobody put to work. Against direct router targeting it surfaces about 80% more addresses. Against random probing it finds roughly 10% more per campaign, and it does so without tripping the rate limiter. For anyone who manages address space (registries, operators, the brokers and leaseholders I work with daily) the interesting part is not the headline number. It is what the number is, and just as importantly, what it is not.
One correction belongs up front, because the rest of the article depends on it: SRA probing discovers router addresses, it does not count routers. That distinction is the whole reason the technique stays trustworthy, and it is the thing most summaries of this research get wrong.
What SRA addresses are, and why they were lying fallow
The Subnet-Router Anycast address is a piece of IPv6 architecture that has been sitting in the spec, largely unused, since RFC 1884 and as it stands today under RFC 4291. Syntactically it is an ordinary unicast address with the host portion set to all zeros. For the subnet 2001:db8:1::/48 the SRA address is 2001:db8:1::0, the prefix followed by nothing. Any router with an interface on that subnet is required to answer a packet sent to it, replying with its own full source address.
That requirement is the lever. The original intent was modest: let an application reach *a* router on a subnet without knowing any specific router's address. Koch's insight is that the same property makes the address a reliable discovery handle. You do not have to guess which of 18 quintillion host addresses on a /64 is live. You aim at the structurally-defined zero address and a compliant router announces itself. The source is candid that implementations differ in their behaviour, so this is a strong signal rather than a guaranteed one, a caveat worth keeping when you read the totals below.
Why the zero address beats brute force
Random IPv6 scanning fails for a reason that is almost arithmetic. The address space is so sparse that the chance of a random probe hitting a live device is, in the source's words, almost zero. The misses are not free, either. Each probe to an unreachable address can draw an ICMP Address Unreachable message, and routers cap how many of those they emit. Push hard and the router suppresses its errors, and your scan goes dark in exactly the places you most wanted to see.
SRA probing sidesteps that failure by changing which ICMP message you provoke. A probe to an enabled SRA address elicits an Echo Reply rather than an error. Echo Replies are not the throttled category; error messages are. So the scanner can sustain a high rate against a stable, structurally-defined endpoint, and the reply stream stays steady where random probing stutters.
In Koch's hitlist comparison the count of Echo-Reply routers held stable across the campaign while random probing's totals swung, and about 9 million router addresses turned up only through SRA. That is the operational case in one figure. The method gains completeness, but its real edge is *repeatability*, and repeatability is what you actually need to track infrastructure over time.
Reading the discovery table without inflating it
This is where discipline earns its keep, because the input set you choose changes the number by an order of magnitude, and it is easy to quote the biggest figure as if it were the truth about the internet.
Koch tested several input sets against roughly 200,000 IPv6 prefixes announced in BGP. The table below is the part of the result that should govern how you cite this work.
| Input set | Addresses probed | Router addresses found | Discovery rate |
|---|---|---|---|
| BGP prefixes, as announced | 200k | 28k | 14% |
| BGP /48 → all /64 subnets | 6.5B | 45M | 0.69% |
| route(6) objects → /64 | 10B | 14M | 0.14% |
| TU Munich Hitlist (unique /64s) | 700M | 72M | 10.3% |
Two readings fall out of this. First, deep partitioning of announced space is expensive and noisy: generating every /64 under a /48 manufactures subnets that no interface owns, so most probes draw errors and the discovery rate collapses below 1%. The /48 partitioning stage alone fabricated about 15 billion candidate targets to scrape a thin yield. Second, probing space already known to be active, such as the TU Munich Hitlist whose /64s come from hosts that were live at some point, is dramatically more efficient: 72 million router addresses from just 700 million requests.
That 72 million is the figure to be careful with. It counts the distinct router *addresses* the hitlist scan answered with, not a census of routers deployed worldwide, and not even a count of distinct physical routers, since a single router can answer on several interfaces. Across every input set combined the study probed 28.2 billion addresses and saw about 135 million router addresses (133 million distinct). These are discovery yields from specific scans, bounded by the inputs that seeded them. Treat them as a floor on what is visible, never as a total of what exists.
The coverage trade-off nobody can engineer away
This method carries a genuine tension. It is not a defect waiting on a patch; it is a choice the operator has to make every time a scan runs.
Probe only the announced prefixes as they appear in BGP and you stay clean and cheap, but you miss the internal, more-specific subnets that hide behind route aggregation. Partition deeper to expose them and you pay in noise: most generated subnets are unassigned, the error volume climbs, and the signal you wanted drowns in negative responses.
The hitlist threads this needle by deriving its /64s from observed activity rather than fabricating them, which is why it wins on efficiency, though it inherits a different weakness. A hitlist is a photograph of the past. It records where hosts *were* active, so it carries deprecated ranges and stale entries, and it will never show you a subnet that has gone live since the list was built. No input set is simultaneously cheap, complete, and current. You pick two and you compensate for the third.
The cross-dataset comparison sharpens the point. Against public IPv6 traceroute measurements, SRA results show less than 5% address-level overlap, yet more than 99% of the Autonomous System Numbers it surfaces already appear in those other datasets. Read together, those two numbers say something precise: SRA is not discovering unknown *networks*, it is discovering unmapped *router interfaces inside known networks*. It fills a gap in the routing layer, leaving the host layer to other tools. It is a complementary lens rather than a replacement map, which is exactly how the source frames it, and exactly how a careful operator should deploy it.
About
I'm Alexander Timokhin, CEO of InterLIR, a Berlin IPv4 marketplace. My working hours go into the things that decide whether a block is worth buying: the RIPE database objects behind it, whether its route origins are clean, what reputation it carries into a transfer. When research like this crosses my desk, the first question I ask is what it changes for the person holding the addresses, and the answer here is mostly about reading numbers the way they were measured.
My RIPE Database Associate certification drilled a single habit into me that I'd press on anyone quoting this work: a discovery count is a measurement, not an inventory. IPv6's routing fabric is plainly deeper than BGP-only views suggested, and that is worth knowing. But the internet most of my customers actually run on is still overwhelmingly IPv4, where the scarce-resource problem is concrete and present, and where the same discipline applies. Know what your number measures before you build a decision on it.
Conclusion
The takeaway is straightforward. SRA probing adds a stable, rate-limit-resistant input to the IPv6 measurement toolbox, and its value comes from being more repeatable than random scanning, not from claiming to see everything. The instinct to scale it across the entire address space is the instinct to resist: blanket /64 partitioning trades a tenfold increase in probes for a sub-1% yield and a flood of errors that can disrupt the very networks being measured.
The practical posture is narrow. Seed from space known to be active, accept that you are sampling rather than counting, and report your findings as the bounded discovery yields they are. The 72-million figure is a useful lower bound on what is visible. Use it as that, and the technique earns its place; quote it as a head-count of the internet's routers, and you have misread an honest piece of work.
Frequently Asked Questions
No. It reports how many router addresses a given scan discovered. Koch's largest single result, 72 million, is the count of distinct router addresses the TU Munich Hitlist scan answered with - not a census of deployed routers, and not even distinct physical routers, since one router can reply on multiple interfaces. Read every figure as a discovery yield bounded by its input set, never as a global total.
A probe to a Subnet-Router Anycast address elicits an ICMP Echo Reply, while random probes to dead addresses draw ICMP error messages. Routers throttle error messages, not Echo Replies, so the SRA reply stream stays stable at high probing rates where random scanning goes dark. Across Koch's campaigns SRA found about 10% more router addresses than random probing, and the Echo-Reply count held steady.
It depends on what you are optimising for. Announced BGP prefixes are cheap and clean but miss aggregated internal subnets. Deep /48-to-/64 partitioning exposes those but yields under 1% and floods you with errors. A hitlist of known-active /64s is by far the most efficient - 72 million addresses from 700 million probes - but it reflects historical activity and misses anything that went live recently. No input is cheap, complete, and current at once.
No, it is complementary. SRA results overlap public traceroute datasets by under 5% at the address level, yet share more than 99% of their Autonomous System Numbers. That means SRA finds unmapped router interfaces inside already-known networks rather than discovering new networks. Use it to fill routing-layer gaps alongside existing maps, not to supersede them.
Yes, which is why aim matters. The source notes that some active scans caused harmful conditions in live IPv6 deployments and required the researchers to collaborate with operators to resolve them. Indiscriminate deep partitioning generates huge volumes of probes against unassigned space, so the responsible path is to seed narrowly from active address space rather than brute-force the routable range.
