Host Anycasting Service
RFC 1546
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.
Abstract
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).
Motivation
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:
telnet archie.net
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.
Architectural Issues
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 duplicate and misroute datagrams
so there clearly are scenarios in which a single datagram could be
delivered to both X and Y. The implication of this conclusion is
that the definition of anycasting in an IP environment is that IP
anycasting provides best effort delivery of an anycast datagram to
one, but possibly more than one, of the hosts that serve the
destination anycast address.
In the second example, suppose that Z sends two datagrams addressed
to the anycast address. The first datagram gets delivered to X. To
which host (X or Y) does the second datagram get delivered? It would
be convenient for stateful protocols like TCP if all of a
connection's datagrams were delivered to the same anycast address.
However, because IP is stateless (and thus cannot keep track of where
earlier datagrams were delivered) and because one of the goals of
anycasting is to support replicated services, it seems clear that the
second datagram can be delivered to either X or Y. Stateful
protocols will have to employ some additional mechanism to ensure
that later datagrams are sent to the same host. Suggestions for how
to accomplish this for TCP are discussed below.
Partridge, Mendez & Milliken [Page 2]
RFC 1546 Host Anycasting Service November 1993
After considering the two examples, it seems clear that the correct
definition of IP anycasting is a service which provides a stateless
Show full document text