Anycast
Anycast is a network addressing and routing methodology in which datagrams from a single sender are routed to the topologically nearest node in a group of potential receivers, though it may be sent to several nodes, all identified by the same destination address.
Addressing methods
|
|
|---|
|
|
|
|
|
|
|
|
|
|
The Internet Protocol and other network addressing systems recognize five main addressing methodologies:
- Anycast addressing routes datagrams to a single member of a group of potential receivers that are all identified by the same destination address. This is a one-to-nearest association.
- Broadcast addressing uses a one-to-many association, datagrams are routed from a single sender to multiple endpoints simultaneously in a single transmission. The network automatically replicates datagrams as needed for all network segments (links) that contain an eligible receiver.
- Multicast addressing uses a one-to-unique many association, datagrams are routed from a single sender to multiple selected endpoints simultaneously in a single transmission.
- Unicast addressing uses a one-to-one association between destination address and network endpoint: each destination address uniquely identifies a single receiver endpoint.
- Geocast refers to the delivery of information to a group of destinations in a network identified by their geographical locations. It is a specialized form of Multicast addressing used by some routing protocols for mobile ad hoc networks.
Details
On the Internet, anycast is usually implemented by using Border Gateway Protocol to simultaneously announce the same destination IP address range from many different places on the Internet. This results in packets addressed to destination addresses in this range being routed to the "nearest" point on the net announcing the given destination IP address. In the past, anycast was suited to connectionless protocols (generally built on UDP), rather than connection-oriented protocols such as TCP that keep their own state. However, assuming a deterministic destination selection for all packets within a session, TCP does work with anycasted destinations. With TCP anycast, there are cases where the receiver selected for any given source may change from time to time as optimal routes change, silently breaking any conversations that may be in progress at the time. These conditions are typically referred to as a "pop switch". To correct this issue, there have been proprietary advancements within custom IP stacks which allow for healing of stateful protocols where it is required.[1] For this reason, anycast is generally used as a way to provide high availability and load balancing for stateless services such as access to replicated data; for example, DNS service is a distributed service over multiple geographically dispersed servers.
Applications
With the growth of the Internet, network services increasingly have high-availability requirements. As a result, operation of anycast services (RFC 4786) has grown in popularity among network operators.[2]
Domain Name System
Nearly all Internet root nameservers are implemented as clusters of hosts using anycast addressing. 12 of the 13 root servers A-M exist in multiple locations, with 11 on multiple continents. (Root server H exists in two U.S. locations. Root server B exists in a single location in the Los Angeles Area.[3])[4][5] The 12 servers with multiple locations use anycast address announcements to provide a decentralized service. This has accelerated the deployment of physical (rather than logical) root servers outside the United States. RFC 3258 documents the use of anycast addressing to provide authoritative DNS services. Many commercial DNS providers have switched to an IP anycast environment to increase query performance, redundancy, and to implement load balancing.
IPv6 transition
In IPv4 to IPv6 transitioning, anycast addressing may be deployed to provide IPv6 compatibility to IPv4 hosts. This method, 6to4, uses a default gateway with the IP address 192.88.99.1, as described in RFC 3068. This allows multiple providers to implement 6to4 gateways without hosts having to know each individual provider's gateway addresses.
Content delivery networks
Content delivery networks may use anycast for actual HTTP connections to their distribution centers, or for DNS. Because most HTTP connections to such networks request static content such as images and style sheets, they are generally short-lived and stateless across subsequent TCP sessions. The general stability of routes and statelessness of connections makes anycast suitable for this application, even though it uses TCP.
Security
Anycast allows any operator whose routing information is accepted by an intermediate router to hijack any packets intended for the anycast address. While this at first sight appears insecure, it is no different from the routing of ordinary IP packets, and no more or less secure. As with conventional IP routing, careful filtering of who is and is not allowed to propagate route announcements is crucial to prevent man-in-the-middle or blackhole attacks. The former can also be prevented by encrypting and authenticating messages, such as using Transport Layer Security, while the latter can be frustrated by onion routing.
Reliability
Anycast is normally highly reliable, as it can provide automatic failover. Anycast applications typically feature external "heartbeat" monitoring of the server's function, and withdraw the route announcement if the server fails. In some cases this is done by the actual servers announcing the anycast prefix to the router over OSPF or another IGP. If the servers die, the router will automatically withdraw the announcement.
"Heartbeat" functionality is important because, if the announcement continues for a failed server, the server will act as a "black hole" for nearby clients; this failure mode is the most serious mode of failure for an anycast system. Even in this event, this kind of failure will only cause a total failure for clients that are closer to this server than any other, and will not cause a global failure.
Mitigating denial-of-service attacks
In denial-of-service attacks, a rogue network host may advertise itself as an anycast server for a vital network service, to provide false information or simply block service.
Anycast methodologies on the Internet may be exploited to distribute DDoS attacks and reduce their effectiveness: As traffic is routed to the closest node, a process over which the attacker has no control, the DDoS traffic flow will be distributed amongst the closest nodes. Thus, not all nodes might be affected. This may be a reason to deploy anycast addressing.[6]
The effectiveness of this technique to divert attacks is questionable, however, because unicast addresses (used for maintenance) can be easy to obtain, at least on IPv6. RFC 2373 defines that "An anycast address must not be used as the source address of an IPv6 packet." Therefore, pinging an anycast address will return the unicast address of the closest node, since the reply must come from a unicast address. An attacker can then attack individual nodes from any location, bypassing anycast addressing methods. This same method works on some, but not all, IPv4 anycast addresses.[7] RFC 2373 also restricted anycast IPv6 addresses to routers only. However, both of these restrictions were lifted in RFC 4291.
Authentication of anycast transmissions may solve this problem.[8]
Local and global nodes
Some anycast deployments on the Internet distinguish between local and global nodes to benefit the local community, by addressing local nodes preferentially. An example is the Domain Name System. Local nodes are often announced with the no-export BGP community to prevent hosts from announcing them to their peers, i.e. the announcement is kept in the local area. Where both local and global nodes are deployed, the announcements from global nodes are often AS prepended (i.e. the AS is added a few more times) to make the path longer so that a local node announcement is preferred over a global node announcement.
See also
- Multihoming
- Line hunting, for an equivalent system for telephones
References
- ↑ Prince, Matthew. "CEO Comment on CloudFlare Blog". CloudFlare Blog. Retrieved 12 August 2014.
- ↑ Abley, J.; Lindqvist, K. (December 2006). "Operation of Anycast Services" (PDF). RFC 4786. The IETF Trust. Retrieved 21 February 2011.
- ↑ Home-page B-root DNS server, visited 8 Feb. 2015
- ↑ "Report on Root Nameserver Locations". Packet Clearing House. Retrieved 21 February 2011.
- ↑ "Root Server Technical Operations Assn". root-servers.org. Retrieved 2013-02-16.
- ↑ "ICANN Factsheet on root server attack on 6 February 2007" (PDF). Factsheet. The Internet Corporation for Assigned Names and Numbers (ICANN). 1 March 2007. Retrieved 21 February 2011.
- ↑ Metz, C. (2002). "IP Anycast: Point-to-(Any) Point Communication (sign-in required)". Internet Computing, IEEE. IEEE. pp. 94–98. Retrieved 3 December 2012.
- ↑ Al-Ibrahim, Mohamed; Cerny, Anton (2003). Gorodetsky, V.; et al., eds. "Authentication of Anycast Communication" (PDF). Lecture Notes in Computer Science, 2003 (Computer Network Society) 2776: 419–423. Retrieved 21 February 2011.
External links
- Best Practices in IPv4 Anycast Routing Tutorial on anycast routing configuration.