Editing Anycast

{{Short description|Network addressing and routing methodology
}}
{{use mdy dates|date=September 2021}}
{{Use American English|date=January 2019}}{{see also|Internet Protocol#Addressing methods}}{{Infobox networking protocol|title=Anycast|image=Anycast2.svg|image size=200px|caption=Visualization of anycast routing.|rfcs={{IETF RFC|1546|2526|4291|4786|plainlink=yes}}...|date={{Start date and age|1989}}|developer=Craig Partridge, Trevor Mendez, Walter Milliken at [[Raytheon_BBN|BBN]]|purpose=To route traffic to the closest server.}}
'''Anycast''' is a network [[address space|addressing]] and [[routing]] methodology in which a single [[IP address]] is shared by devices (generally servers) in multiple locations. [[Router (computing)|Routers]] direct packets addressed to this destination to the location nearest the sender, using their normal [[Routing algorithms|decision-making algorithms]], typically the lowest number of [[Border gateway protocol|BGP]] [[Hop (networking)|network hops]]. Anycast routing is widely used by [[content delivery network]]s such as web and [[name server]]s, to bring their content closer to end users.

==History==
The first documented use of anycast routing for topological load-balancing of Internet-connected services was in 1989;<ref name="woodcock-best-practices">{{cite web |last1=Woodcock |first1=Bill |title=Best Practices in Anycast Routing |url=https://www.pch.net/resources/Tutorials/anycast/Anycast-v06.pdf |publisher=Packet Clearing House |date=June 1996}}</ref><ref name="hernandez-enog">{{cite web |last1=Hernandez |first1=Gael |title=Building and Operating a Global Anycast Network |url=https://www.enog.org/wp-content/uploads/presentations/enog-14/20-Anycast-DNS-network-ENOG14.pdf |publisher=Eurasia Network Operators Group |date=10 October 2017}}</ref> the technique was first formally documented in the IETF four years later.{{Ref RFC|1546}} It was first applied to critical infrastructure in 2001 with the anycasting of the [[Root_name_server#Root_server_addresses|I-root nameserver]].<ref name="hernandez-enog" />

===Early objections===
Early objections to the deployment of anycast routing centered on the perceived conflict between long-lived [[Transmission Control Protocol|TCP]] connections and the volatility of the Internet's routed topology. In concept, a long-lived connection, such as an FTP file transfer (which can take hours to complete for large files) might be re-routed to a different anycast instance in mid-connection due to changes in network topology or routing, with the result that the server changes mid-connection, and the new server is not aware of the connection and does not possess the TCP connection state of the previous anycast instance.

In practice, such problems were not observed, and these objections dissipated by the early 2000s. Many initial anycast deployments consisted of DNS servers, using principally [[User Datagram Protocol|UDP]] transport.<ref>{{cite web |last1=Woodcock |first1=Bill |title=TCP and Anycast |url=https://www.mail-archive.com/nanog@nanog.org/msg103547.html |website=NANOG mailing list archive |publisher=North American Network Operators Group |date=14 November 2019}}</ref><ref name="hernandez-enog" /> Measurements of long-term anycast flows revealed very few failures due to mid-connection instance switches, far fewer (less than 0.017%<ref name="levine-nanog">{{cite web |last1=Levine |first1=Matt |last2=Lyon |first2=Barrett |last3=Underwood |first3=Todd |title=TCP Anycast: Don't Believe the FUD - Operational experience with TCP and Anycast |url=https://archive.nanog.org/meetings/nanog37/presentations/matt.levine.pdf |publisher=North American Network Operators Group |date=June 2006}}</ref> or "less than one flow per ten thousand per hour of duration"<ref name="woodcock-best-practices" /> according to various sources) than were attributed to other causes of failure. Numerous mechanisms were developed to efficiently share state between anycast instances.<ref>{{cite web |last1=Herrin |first1=William |title=Anycast TCP Architecture |url=https://bill.herrin.us/network/anycasttcp.html |access-date=11 October 2021}}</ref> And some TCP-based protocols, notably HTTP, incorporated "redirect" mechanisms, whereby anycast service addresses could be used to locate the nearest instance of a service, whereupon a user would be redirected to that specific instance prior to the initiation of any long-lived stateful transaction.<ref name="woodcock-best-practices" /><ref>{{cite web |last1=Katz-Bassett |first1=Ethan |last2=Gao |first2=Ryan |title=Impact of TCP Loss on Regional Application Performance |url=https://www.microsoft.com/en-us/research/uploads/prod/2019/07/regionalloss.pdf |publisher=Microsoft |date=July 2019 |quote=Azure Frontdoor uses anycast redirection to direct users to a nearby edge.}}</ref>

==Internet Protocol version 4==
Anycast can be implemented via [[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, even 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.

==Internet Protocol version 6==
Anycast is supported explicitly in the [[IPv6 address]]ing architecture.{{Ref RFC|4291}} The lowest address within an IPv6 [[Subnetwork|subnet]] (interface identifier 0) is reserved as the "Subnet Router" anycast address.  In addition, the highest 128 interface identifiers within a subnet are also reserved as anycast addresses.{{Ref RFC|2526}}
{| class="wikitable"
|+Reserved Anycast address's
!
!Subnet Prefix
!''interface identifier''
!CIDR notation
|-
!Subnet router
|any
|::
|::0/124
|-
|'''Anycast'''
|any
|ffff:ffff:ffff:ff80 to ffff:ffff:ffff:ffff
|::ffff:ffff:ffff:ff80/121
|-
|'''Mobility Support''' 
|any
|ffff:ffff:ffff:fffe
|::ffff:ffff:ffff:fffe/124
|}
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 ([[Hop (networking)|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 has grown in popularity among network operators.{{Ref RFC|4786}}

===Domain Name System===
All Internet [[root nameserver]]s are implemented as clusters of hosts using anycast addressing.{{Ref RFC|3258}} All 13 root servers A–M exist in multiple locations, with 11 on multiple continents. (Root servers B and H exist in two U.S. locations.)<ref>Home-page [http://www.isi.edu/b-root/ B-root DNS server], visited 8 Feb. 2015</ref><ref>{{cite web
   | url        = http://pch.net/root-servers
   | title      = Report on Root Nameserver Locations
   | publisher  = [[Packet Clearing House]]
   | access-date = 21 February 2011}}</ref><ref>{{cite web |title=Root Server Technical Operations Assn |url=http://www.root-servers.org/ |publisher=root-servers.org |access-date=2013-02-16}}</ref> 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]]. Many commercial DNS providers have switched to an IP anycast environment to increase query performance and redundancy, and to implement load balancing.<ref name="hernandez-enog" />

===IPv6 transition===
In [[IPv6 transition mechanisms|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 {{IPaddr|192.88.99.1}}.{{Ref RFC|3068}} This allows multiple providers to implement [[6to4]] gateways without hosts having to know each individual provider's gateway addresses. 6to4 has been deprecated{{Ref RFC|7526}} in response to native IPv6 becoming more prevalent.

===Content delivery networks===
[[Content delivery network]]s may use anycast for actual [[HTTP]] connections to their distribution centers, or for [[Domain Name System|DNS]]. Because most HTTP connections to such networks request static content such as images and [[Style sheet (web development)|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 [[Transmission Control Protocol|TCP]].<ref name="levine-nanog" /><ref name="woodcock-best-practices" />

===Connectivity between Anycast and Multicast network===
Anycast rendezvous point can be used in [[Multicast]] Source Discovery Protocol (MSDP) and its advantageous application as Anycast RP is an intra-domain 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.<ref>{{cite web |title=Anycast Rendezvous Point |url=https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/anycast.html |publisher=Cisco Systems |date=1 June 2001}}</ref>

==Security==
Anycast allows any operator whose routing information is accepted by an intermediate [[Router (computing)|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 [[Internet Protocol|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 attack|man-in-the-middle]] or [[Packet drop attack|blackhole attack]]s. 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]] without adding complexity or new potential points of failure.  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 [[Open Shortest Path First|OSPF]] or another [[Interior gateway protocol|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 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. However, even the automation necessary to implement "heartbeat" routing withdrawal can itself add a potential point of failure, as seen in the [[2021 Facebook outage]].

==Mitigation of denial-of-service attacks==
In [[denial-of-service attack]]s, 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.<ref>{{cite web
   | url        = http://www.icann.org/announcements/factsheet-dns-attack-08mar07_v1.1.pdf
   | title      = ICANN Factsheet on root server attack on 6 February 2007
   | work       = Factsheet
   | publisher  = [[ICANN|The Internet Corporation for Assigned Names and Numbers]] (ICANN)
   | date       = 1 March 2007
   | access-date = 21 February 2011}}</ref>
The effectiveness of this technique depends upon maintaining the secrecy of any unicast addresses associated with anycast service nodes, however, since an attacker in possession of the unicast addresses of individual nodes can attack them from any location, bypassing anycast addressing methods.<ref>{{cite journal
   | author     = Metz, C.
   | title      = IP Anycast: Point-to-(Any) Point Communication (sign-in required)
   | journal       = IEEE Internet Computing
   | volume     = 6
   | issue      = 2
   | pages      = 94–98
   | publisher  = [[IEEE]]
   | year       = 2002
   | doi = 10.1109/4236.991450
 }}</ref>

==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 [[Autonomous system (Internet)|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.<ref>{{Cite book|url=https://books.google.com/books?id=Tyte75MFbHkC&q=anycast+local+and+global+nodes&pg=PA102|title=Advanced Internet Protocols, Services, and Applications|last1=Oki|first1=Eiji|last2=Rojas-Cessa|first2=Roberto|last3=Tatipamula|first3=Mallikarjun|last4=Vogt|first4=Christian|date=2012-04-24|publisher=John Wiley & Sons|isbn=978-0-470-49903-0|pages=102 & 103|language=en|archive-url=https://web.archive.org/web/20200105061928/https://books.google.ca/books?id=Tyte75MFbHkC&lpg=PA103&ots=p3K484ueyF&dq=anycast%20local%20and%20global%20nodes&pg=PA102%23v=onepage&q=anycast%20local%20and%20global%20nodes&f=false|archive-date=2020-01-05|url-status=live}}</ref>

==See also==
{{Portal|Internet}}
* [[Multihoming]]
* [[Line hunting]], for an equivalent system for telephones

==References==
{{Reflist}}

==External links==
*[http://www.pch.net/resources/papers/ipv4-anycast/ipv4-anycast.pdf Best Practices in IPv4 Anycast Routing] Tutorial on anycast routing configuration.

[[Category:Computer network technology]]
[[Category:Internet architecture]]
[[Category:Multihoming]]
[[Category:Domain Name System]]