[Question] Does this list cover all Anycast addresses?

[1366613]

Any IP can be an Anycast address. As I see, this tool's only listing prefixes which are detected to include only Anycast addresses. What about an IP address that might be an Anycast address but is not part of any prefixes with all the members being Anycast addresses? Anyway, I'm not seeing any CIDR notations which would resolve to a single IP address, so anycast-prefixes is not handling any such cases at all, which means it's not actually mentioning a large portion of Anycast addresses. Am I wrong?

[benjojo]

The prober will search for up to 5 IPs that ping inside a IP Prefix, and if it finds one and finds that it is then anycast, it declares the whole block anycast.

The CSV files tell you what IP in the block is anycast (and pings)

[1366613]

@benjojo

The prober will search for up to 5 IPs that ping inside a IP Prefix, and if it finds one and finds that it is then anycast, it declares the whole block anycast.

I'm not an expert on this topic, but isn't this going to lead to a lotta false positives and false negatives in the end? Isn't this a weak and fundamentally flawed method to identify Anycast addresses?

[benjojo]

Isn't this a weak and fundamentally flawed method to identify Anycast addresses?

Anycast detection is always going to be non perfect. The detection mechanism itself is quite good at accurately detecting anycast addresses with a global footprint.

The address selection is limited in order to prevent having to test everything inside a /16 for example, Since most anycast prefixes are (for traffic engineering reasons) separate BGP prefix announcements anyway, this system works well in most cases.

The case when it will false negative are:

• When a IPs in a prefix are only partially anycast (quite rare in my experience, the only one that comes off the top of my head is Apple)
• When none of the IPs in a tested prefix are responding to ICMP Ping
• There is no known IPv6 address that pings

The case when it will false positive are:

• Very rare situations where the network under test have round robin packet "load balancing", and are sending traffic from two different carriers with different peering footprints to bgp.tools own counter anycast.

The system is far more likely to false negative than positive. The fact that it can miss "mixed" prefixes is a downside that outweighs the huge extra work of testing every IP in a prefix.

A version of this method has been done since 2015, with very few false negatives, and after 2015 a extremely similar setup has been repeated in academic settings

The method I believe is robust enough, however like all internet measurements, there will always be "weird stuff" that is hard to account for