Anycast

Anycast is a network addressing and routing methodology in which a single destination address has multiple routing paths to two or more endpoint destinations. Routers will select the desired path on the basis of number of hops, distance, lowest cost, latency measurements or based on the least congested route. Anycast networks are widely used for content delivery network (CDN) products to bring their content closer to the end user.

Visualization of Anycast routing.

Addressing methods
Routing schemes
Unicast

Broadcast

Multicast

Anycast

Geocast

The Internet Protocol and other network addressing systems recognize five main addressing methods:

  • Unicast addressing uses a one-to-one association between a sender and destination: each destination address uniquely identifies a single receiver endpoint.
  • Broadcast uses a one-to-all association; a single datagram from one sender is routed to all of the possibly multiple endpoints associated with the broadcast address. The network automatically replicates datagrams as needed to reach all the recipients within the scope of the broadcast, which is generally an entire network subnet.
  • Multicast addressing uses a one-to-many-of-many or many-to-many-of-many association; datagrams are routed simultaneously in a single transmission to many recipients. It differs from broadcast in that the destination address designates a subset, not necessarily all, of the accessible nodes.
  • Anycast addressing is a one-to-one-of-many association where datagrams are routed to any single member of a group of potential receivers that are all identified by the same destination address. The routing algorithm selects the single receiver from the group based on least-expensive routing metric. In practice, this means that packets are routed to the topologically-nearest member of an anycast group. Anycasting in the Internet architecture was first described in RFC 1546 [1]
  • 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.

Internet Protocol version 4

Anycast can be implemented by using Border Gateway Protocol (BGP). Multiple hosts (usually in different geographic areas) are given the same unicast IP address and different routes to the address are announced through BGP. Routers consider these to be alternative routes to the same destination, though they are actually routes to different destinations with the same address. As usual, routers select a route by whatever distance metric is in use (the least cost, least congested, shortest). Selecting a route in this setup amounts to selecting a destination.

The pitfall of this approach is that a connection to an anycast address may fail because the network can change the routing of packets in mid-connection due to congestion or changes in the network, with the result that the destination changes mid-connection, though the new destination is not aware of the connection and is not maintaining the connection state. These conditions are typically referred to as a "PoP switch". With a normal unicast address a routing change would not be a problem, as this merely results in a different route to the same eventual destination. All packets within a connection do not normally need to follow the same path. But when the address is actually an anycast address masquerading as a unicast address (as in this design), a routing change could be a destination change.

Because of the possibility of a "PoP switch" in IPv4, anycast is generally used with connectionless protocols based on UDP, as a way to provide high availability and load balancing for stateless services. For example, one of the well-known applications of IPv4 anycast is the Domain Name System (DNS). This is well-suited to anycast because it is a UDP-based service providing connectionless access to domain name data which is replicated across multiple, geographically-dispersed, stateless servers, with severe demands for availability and scalability.

Because anycast is more error-prone with connection-oriented protocols such as TCP where the destination maintains state, it is less commonly used with these protocols. Some custom IP stacks use proprietary methods to provide healing of stateful protocols when necessary,[2] mitigating problems due to anycast PoP switches. These methods usually involve some form of Network function virtualization[3] in form of packet rewriting as has been demonstrated by AWS HyperPlane,[4][5] and Google Maglev[6] and/or packet encapsulation as laid out by protocols like Generic Routing Encapsulation, IPOP.

Internet Protocol version 6

Anycast is supported explicitly in IPv6. RFC 4291, which covers IPv6 addressing architecture, reserves Interface Identifier 0 within an IPv6 subnet as the "Subnet Router" anycast address. In addition, RFC 2526 reserves a block of 128 Interface Identifiers within a subnet as anycast addresses.

Most IPv6 routers on the path of an anycast packet through the network will not distinguish it from a unicast packet, but special handling is required from the routers near the destination (that is, within the scope of the anycast address) as they are required to route an anycast packet to the "nearest" interface within that scope which has the proper anycast address, according to whatever measure of distance (hops, cost, etc.) is being used.

The method used in IPv4 of advertising multiple routes in BGP to multiply-assigned unicast addresses also still works in IPv6, and can be used to route packets to the nearest of several geographically dispersed hosts with the same address. This approach, which does not depend on anycast-aware routers, has the same use-cases together with the same problems and limitations as in IPv4.

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.[7]

Domain Name System

All Internet root nameservers are implemented as clusters of hosts using anycast addressing. All thirteen root servers A–M exist in multiple locations, with eleven on multiple continents. (Root servers B and H exist in two U.S. locations.[8][9][10]) The servers 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 and 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.

Connectivity between Anycast and Multicast network

Anycast rendezvous point can be used in Multicast Source Discovery Protocol (MSDP) and it's advantageous application as Anycast RP is an intradomain feature that provides redundancy and load-sharing capabilities. If the multiple Anycast rendezvous point is used, IP routing automatically will select the topologically closest rendezvous point for each source and receiver. It would provide a multicast network with the fault tolerance requirements.[11]

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.

Mitigation of 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.[12]

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. Now obsoleted RFC 2373 defined 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.[13] 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.[14]

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.[15]

gollark: There's a library for that, but I need to add custom parsing bits.
gollark: https://github.com/soasme/nim-markdown/
gollark: nim-markdown
gollark: Nope, equally slow.
gollark: I'm going to test it again with my custom parsing logic disabled.

See also

References
  1. Partridge, C.; Mendez, T.; Milliken, W. (November 1993). "Host Anycasting Service" (PDF). RFC 1546. The IETF Trust. Retrieved 14 August 2019.
  2. Prince, Matthew. "CEO Comment on CloudFlare Blog". CloudFlare Blog. Retrieved 12 August 2014.
  3. Network Functions Virtualization (NFV) Use Cases, ETSI GS NFV 001 v1.1.1 (2013-10)
  4. MacCarthaigh, Colm. "HyperPlane". YouTube. Retrieved 27 February 2019.
  5. MacCarthaigh, Colm. "Load Balancing at Hyperscale". AtScaleConference. Retrieved 27 February 2019.
  6. Eisenbud, Daniel. "A Fast and Reliable Software Network Load Balancer". Google. Retrieved 27 February 2019.
  7. Abley, J.; Lindqvist, K. (December 2006). "Operation of Anycast Services" (PDF). RFC 4786. The IETF Trust. Retrieved 21 February 2011.
  8. Home-page B-root DNS server, visited 8 Feb. 2015
  9. "Report on Root Nameserver Locations". Packet Clearing House. Retrieved 21 February 2011.
  10. "Root Server Technical Operations Assn". root-servers.org. Retrieved 2013-02-16.
  11. https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/anycast.html
  12. "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.
  13. Metz, C. (2002). "IP Anycast: Point-to-(Any) Point Communication (sign-in required)". IEEE Internet Computing. IEEE. 6 (2): 94–98. doi:10.1109/4236.991450.
  14. Al-Ibrahim, Mohamed; Cerny, Anton (2003). Gorodetsky, V.; et al. (eds.). "Authentication of Anycast Communication". Lecture Notes in Computer Science. Computer Network Society. 2776: 419–423. doi:10.1007/978-3-540-45215-7_36. ISBN 978-3-540-40797-3.
  15. Oki, Eiji; Rojas-Cessa, Roberto; Tatipamula, Mallikarjun; Vogt, Christian (2012-04-24). Advanced Internet Protocols, Services, and Applications. John Wiley & Sons. pp. 102 & 103. ISBN 978-0-470-49903-0. Archived from the original on 2020-01-05.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.