One of the first and most popular deployments of anycast infrastructure was for Domain Name System (DNS) root servers. It has been proven to improve resolution time and resilience against Distributed Denial of Service (DDoS) attacks.
Following the example of the root servers, several other DNS operators started to provide their services on anycast networks, both for public resolvers and authoritative nameservers.
Anycast has also been adopted by several cloud providers, Content Delivery Networks (CDNs), and DDoS protection services, among others.
Why measure anycast?
Due to its growing popularity, identifying which addresses are anycasted and from where they are announced is becoming fundamentally important to provide a more accurate assessment of the Internet’s resilience.
Unfortunately, the IPv4 approach to anycast relies on the principle of assigning the same unicast address to multiple hosts and leveraging routing to implement the anycast addressing. Due to the opacity of routing, identifying which address is anycast is not straightforward.
Traditional methods of measuring anycast are based on the Great Circle Distance (GCD) technique. The basic idea behind GCD is that if two probes in the world reach a node with a latency that violates the speed of the light, the node must be anycast.
The GCD approach has proven to be effective and results in a tool for anycast measurement called iGreedy.
However, the GCD approach has some disadvantages; it requires a significant number (~200) of geo-located probes in order to perform an accurate measurement, and has a relevant footprint in terms of generated traffic. RIPE Atlas offers a solution to this, however, this can be unsuitable for a long-term census of the entire Internet.
A new approach
In a recent study headed by the University of Twente, we proposed a new measurement and inference technique, MAnycast², which relies on an anycast testbed to efficiently detect anycast prefixes.
The idea behind MAnycast² is quite simple: We send ICMP echo-requests with our anycast IP address as a source, from all of the anycast nodes in our testbed. The traffic of the ICMP echo-responses to the anycast IP will be then routed back on a single node, if the target is unicast and on multiple nodes, in case the target is anycast.
Compared to traditional anycast detection techniques, MAnycast² does not rely on latency measurements. Instead, it leverages the routing system to discriminate anycast deployments.
As part of a paper that we recently presented on at the Internet Measurement Conference (IMC 2020), we tested MAnycast² using two different anycast platforms — Tangled and PEERING. We were able to perform an anycast census of the entire ISI IPv4 hit-list in ∼2.5 hours, with only 10 pings per target IP address, demonstrating the lower traffic footprint and the speed of our methodology.
The results obtained in the census are promising. We validated the finding of MAnycast² with public ground-truth of anycast networks (for example, DNS root servers), reaching operators for confirmations and using a GCD-based tool (iGreedy) with RIPE Atlas.
The comparison shows low error rates, with some exceptions, which indicates some open challenges remain to further improve this methodology.
Fewer false positives
MAnycast² was able to classify 15,540 anycast /24 prefixes and 3,451,133 unicast /24 prefixes.
The comparison with iGreedy results shows low false-negative rates (anycast classified as unicast), and zero false-positive rates (unicast classified as anycast) when it comes to answers received on four or more anycast VPs. False positives often happen due to route instability where answers are received only on two or three anycast nodes.
The combination of the GCD and the MAnycast² approaches show promising results and let us map and confirm 5,987 anycast prefixes.
In the future, we will focus on increasing the accuracy of our methodology and on performing a regular census of the anycast deployment on the Internet.
Can I deploy MAnycast² on my anycast network?
Feel free to reach out to us for any information on how to deploy MAnycast² on your network.
Raffaele Sommese is a second-year PhD candidate at the University of Twente, The Netherlands.
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.