User:David MacQuigg/Sandbox/Anycasting: Difference between revisions
imported>David MacQuigg No edit summary |
imported>David MacQuigg (Updated intro) |
||
Line 1: | Line 1: | ||
{{TOC|right}} | {{TOC|right}} | ||
'''Anycasting''' is an Internet Protocol routing technique in which the same [[IP address]] may exist at several points in the network, with the caveat that each instance of the address must provide exactly the same services. While the term anycast came into prominence with [[IPv6]] work,<ref name=RFC4291>{{citation | This is a draft version in which I have added lots of editorial footnotes, to be deleted in the finished version.--[[User:David MacQuigg|David MacQuigg]] 17:34, 16 October 2009 (UTC) | ||
'''Anycasting''' is an Internet Protocol routing technique in which the same [[IP address]] may exist at several points in the network, with the caveat that each instance of the address must provide exactly the same services. The technique is useful for load balancing, fault tolerance, and security against a [[Denial of service|DoS]] attack.<ref> | |||
[[IP blacklist|IP blacklists]] commonly use multiple servers to simply absorb the frequent attacks they endure from criminals whose IP addresses are listed. | |||
</ref> | |||
A typical application is a heavily-used database like DNS, where the same data can be provided from any number of identical servers. Applications are not limited to "read-only" however. See the [[Sinkhole|sinkholes]] operational example below. | |||
Traditionally, an IP address needed to be unique. This would be absolutely true in a single network with no segmentation. The Internet, however, is a collection of networks linked by routers. When the same address is claimed by servers on different networks, an upstream router simply assumes it is the same server as seen via different routes. It picks the shortest path for its routing table, and ignores the rest. A router supporting anycast keeps these routes available as alternatives. Alternative routes may be selected randomly, in a cyclic pattern, or depending on external factors, such as the current load reported by each server.<ref> | |||
I'm following Einstein's rule here - Make things as simple as possible, but no simpler. I'm not an expert in routing. Tell me if I've made this too simple.</ref> | |||
While the term anycast came into prominence with [[IPv6]] work,<ref name=RFC4291>{{citation | |||
| id = RFC 4291 | | id = RFC 4291 | ||
| title = IP Version 6 Addressing Architecture. | | title = IP Version 6 Addressing Architecture. | ||
| first1 =R.|last1=Hinden |first2= S. | last2=Deering. | | first1 =R.|last1=Hinden |first2= S. | last2=Deering. | ||
| date = February 2006 | | date = February 2006 | ||
| url = http://tools.ietf.org/html/rfc4291}}</ref> it can be quite useful with IPv4 | | url = http://tools.ietf.org/html/rfc4291}}</ref> it can be quite useful with IPv4. 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",<ref name=>{{citation | ||
| url = http://www.net.cmu.edu/pres/anycast/Deploying%20IP%20Anycast.ppt | | url = http://www.net.cmu.edu/pres/anycast/Deploying%20IP%20Anycast.ppt | ||
| title = Deploying IP Anycast | | title = Deploying IP Anycast | ||
| first1 = Kevin | last1 = Miller | | first1 = Kevin | last1 = Miller | ||
| date = NANOG 29 – October 2003}}</ref> which is different from the IPv6 specific work in <nowiki>RFC 4291</nowiki>, which superseded the <nowiki>RFC 3513</nowiki> mentioned in the Miller paper. | | date = NANOG 29 – October 2003}}</ref> which is different from the IPv6 specific work in <nowiki>RFC 4291</nowiki>, which superseded the <nowiki>RFC 3513</nowiki> mentioned in the Miller paper. | ||
The IPv6 architecture describes it as: | The IPv6 architecture describes it as: |
Revision as of 12:34, 16 October 2009
This is a draft version in which I have added lots of editorial footnotes, to be deleted in the finished version.--David MacQuigg 17:34, 16 October 2009 (UTC)
Anycasting is an Internet Protocol routing technique in which the same IP address may exist at several points in the network, with the caveat that each instance of the address must provide exactly the same services. The technique is useful for load balancing, fault tolerance, and security against a DoS attack.[1] A typical application is a heavily-used database like DNS, where the same data can be provided from any number of identical servers. Applications are not limited to "read-only" however. See the sinkholes operational example below.
Traditionally, an IP address needed to be unique. This would be absolutely true in a single network with no segmentation. The Internet, however, is a collection of networks linked by routers. When the same address is claimed by servers on different networks, an upstream router simply assumes it is the same server as seen via different routes. It picks the shortest path for its routing table, and ignores the rest. A router supporting anycast keeps these routes available as alternatives. Alternative routes may be selected randomly, in a cyclic pattern, or depending on external factors, such as the current load reported by each server.[2]
While the term anycast came into prominence with IPv6 work,[3] it can be quite useful with IPv4. 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",[4] which is different from the IPv6 specific work in RFC 4291, which superseded the RFC 3513 mentioned in the Miller paper.
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).[3]
Contrast to multicast
Multicasting is essentially a mirror image of anycasting. In multicasting, a source S sends to a group G of recipients. 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.
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.
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.
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: While the official list has tens of named servers, there are actually hundreds of geographically distributed machines.
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.
References
- ↑ IP blacklists commonly use multiple servers to simply absorb the frequent attacks they endure from criminals whose IP addresses are listed.
- ↑ I'm following Einstein's rule here - Make things as simple as possible, but no simpler. I'm not an expert in routing. Tell me if I've made this too simple.
- ↑ 3.0 3.1 Hinden, R. & S. Deering. (February 2006), IP Version 6 Addressing Architecture., RFC 4291
- ↑ Miller, Kevin (NANOG 29 – October 2003), Deploying IP Anycast