Anycasting

Please create the "Talk page". Just click this Talk page link and save the page.

While the term anycast came into prominence with IPv6 work, it can be quite useful with IPv4. The technique, while somewhat counterintuitive, is useful for load distribution, fault tolerance, or both. IPv4 has no infrastructure explicitly for anycast while IPv6 does, but the technique can be applied in both areas, with different address structures. Miller discusses "shared anycast", which is different than the IPv6 specific work in RFC 4291, which superceded the RFC 3513 mentioned in the Miller paper.

Traditionally, an IP address, inside a given routing/addressing domain, needed to be unique. In this discussion, assume the IPv4 address 3.1.1.1 belongs to a single server. That is indeed true in a "flat" address space of a single IP subnet (i.e., network prefix). When the environment is split by routers into logical subnets, remember that a router commonly receives different paths to what it assumes is the same address, picks the "best", and puts the associated prefix and outgoing address and puts that in its routing table. It was realized, however, that the router, unless very deliberate steps are taken, really does not know if two potential paths to an address are merely different ways to get to the same instance of an address, or if they represent unique paths to different instances of the address.

As long as the behavior of multiple instances of the address are identical, it makes no difference, to the requesting client, if server A, B, or C actually executes the request.

The IPv6 architecture describes it as:

Anycast: An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocols' measure of distance).

Contrast to multicast

Multicasting is essentially a mirror image of anycasting. In multicasting, a source S sends to a group of recipients, G. Broadcasting is a special case where G contains all possible recipients. It is assumed that G has more than one member.

An anycast source S sends to a destination address D, which S believes to be a single recipient. In reality, there are multiple instances of D, any one of which can respond to the message addressed to D.

(CC) Image: Howard C. Berkowitz
Load distribution example

Load balancing case

In the illustration to the left, there are three instances of a server, which carries out a read-only function; it makes no difference to the client which server actually satisfies its request.

The simplistic routing mechanism here adds up the costs of routes to a destination. From router 1, server A is closest. From router 3, server C has the least cost.

(CC) Image: Howard C. Berkowitz
Single client with all servers working

Fault tolerance case

Now, simplify the scenario to have but one host. As long as server A is up, router 1 will see a cost of 1 to reach server A. The routing process was aware of other routes to 3.1.1.1, but there was a cost of 2 to server B and a cost of 3 to server C. Router 1 only put the lowest-cost route into its routing table.

(CC) Image: Howard C. Berkowitz
Single client after failure

But what if server A fails? The router knows other paths to the same address, so it will install the path that goes through router 2. The client will still receive exactly the same service from exactly the same address.

Of course, if client 2 reconnected to Router 3, it would have the lowest cost path to server C as long as Server C stayed up. If Server C fails, router 3 would change its route to 3.1.1.1 to the path to Server B.

Operational examples

Anycast works well for any application that is read-only and where the relevant servers have a common database. One common application is the root servers for the Domain Name Service.

Another application is in Internet Protocol infrastructure security, where the "application protocol" is IP itself. Large networks, especially of Internet Service Providers, may have multiple sinkholes for diverting hostile traffic away from the true IP address of the server or router under attack, as well as providing a place to analyze the threat. When an attack is detected, the server under attack would be useless due to overload, so its address is effectively reassigned as the more-preferred anycast address of a set of sinkholes. The sinkhole nearest the ingress router does the analysis of a single-stream denial of service (DoS) attack, while anycast-addressed sinkholes respond well under distributed denial of service (DDoS) attack.

Especially when a sinkhole anycast technique is used to protect routers, especially Border Gateway Protocol, under attack, it must be possible to divert attack traffic directed at the usual production address of the router interface, but still have either an additional, internal-only address on the interface, or another means of communicating with the router (e.g., a physically separate interface) that can be used to reconfigure the router. This is less often required on servers, which are most often protected by router configuration, but still may be appropriate if defensive code needs to be inserted into the router, yet not diverted away from it by the anycast process. When using anycast with routers, it is best to use a routing protocol, such as the Border Gateway Protocol or Open Shortest Path First, that has an explicit router identifier that can disambiguate different announcements of the same address.