Host Anycasting Service (RFC1546)
Original Publication Date: 1993-Nov-01
Included in the Prior Art Database: 2019-Feb-13
Internet Society Requests For Comment (RFCs)
C. Partridge: AUTHOR [+2]
This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Network Working Group C. Partridge Request for Comments: 1546 T. Mendez Category: Informational W. Milliken BBN November 1993
Host Anycasting Service
Status of this Memo
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. Insofar as is possible, this memo tries to be agnostic about how the service is actually provided by the internetwork. This memo describes an experimental service and does not propose a protocol. This memo is produced by the Internet Research Task Force (IRTF).
There are a number of situations in networking where a host, application, or user wishes to locate a host which supports a particular service but, if several servers support the service, does not particularly care which server is used. Anycasting is a internetwork service which meets this need. A host transmits a datagram to an anycast address and the internetwork is responsible for providing best effort delivery of the datagram to at least one, and preferably only one, of the servers that accept datagrams for the anycast address.
The motivation for anycasting is that it considerably simplifies the task of finding an appropriate server. For example, users, instead of consulting a list of archie servers and choosing the closest server, could simply type:
Partridge, Mendez & Milliken [Page 1]
RFC 1546 Host Anycasting Service November 1993
and be connected to the nearest archie server. DNS resolvers would no longer have to be configured with the IP addresses of their servers, but rather could send a query to a well-known DNS anycast address. Mirrored FTP sites could similarly share a single anycast address, and users could simply FTP to the anycast address to reach the nearest server.
Adding anycasting to the repertoire of IP services requires some decisions to be made about how to balance the architectural requirements of IP with those of anycasting. This section discusses these architectural issues.
The first and most critical architectural issue is how to balance IP’s stateless service with the desire to have an anycast address represent a single virtual host. The best way to illustrate this problem is with a couple of examples. In both of these examples, two hosts (X and Y) are serving an anycast address and another host (Z) is using the anycast address to contact a service.
In the first example, suppose that Z sends a UDP datagram addressed to the anycast address. Now, given that an anycast address is logically considered the address of a single virtual host, should it be possible for the datagram to be delivered to both X and Y? The answer to this question clearly has to be yes, delivery to both X and Y is permissible. IP is allowed to...