As per Relevance of the word datagram, we have this rfc below:
Network Working Group C.
Request for Comments: 1546 T.
Category: Informational W.
November 1993
Host Anycasting
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This RFC describes an internet anycasting service for IP.
primary purpose of this memo is to establish the semantics of
anycasting service within an IP internet. Insofar as is possible
this memo tries to be agnostic about how the service is
provided by the internetwork. This memo describes an
service and does not propose a protocol. This memo is produced
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
particular service but, if several servers support the service,
not particularly care which server is used. Anycasting is
internetwork service which meets this need. A host transmits
datagram to an anycast address and the internetwork is
for providing best effort delivery of the datagram to at least one
and preferably only one, of the servers that accept datagrams for
anycast address
The motivation for anycasting is that it considerably simplifies
task of finding an appropriate server. For example, users,
of consulting a list of archie servers and choosing the
server, could simply type
telnet archie.
Partridge, Mendez & Milliken [Page 1]
RFC 1546 Host Anycasting Service November 1993
and be connected to the nearest archie server. DNS resolvers
no longer have to be configured with the IP addresses of
servers, but rather could send a query to a well-known DNS
address. Mirrored FTP sites could similarly share a single
address, and users could simply FTP to the anycast address to
the nearest server
Architectural
Adding anycasting to the repertoire of IP services requires
decisions to be made about how to balance the
requirements of IP with those of anycasting. This section
these architectural issues
The first and most critical architectural issue is how to
IP's stateless service with the desire to have an anycast
represent a single virtual host. The best way to illustrate
problem is with a couple of examples. In both of these examples,
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
to the anycast address. Now, given that an anycast address
logically considered the address of a single virtual host, should
be possible for the datagram to be delivered to both X and Y?
answer to this question clearly has to be yes, delivery to both X
Y is permissible. IP is allowed to duplicate and misroute
so there clearly are scenarios in which a single datagram could
delivered to both X and Y. The implication of this conclusion
that the definition of anycasting in an IP environment is that
anycasting provides best effort delivery of an anycast datagram
one, but possibly more than one, of the hosts that serve
destination anycast address
In the second example, suppose that Z sends two datagrams
to the anycast address. The first datagram gets delivered to X.
which host (X or Y) does the second datagram get delivered? It
be convenient for stateful protocols like TCP if all of
connection's datagrams were delivered to the same anycast address
However, because IP is stateless (and thus cannot keep track of
earlier datagrams were delivered) and because one of the goals
anycasting is to support replicated services, it seems clear that
second datagram can be delivered to either X or Y.
protocols will have to employ some additional mechanism to
that later datagrams are sent to the same host. Suggestions for
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
definition of IP anycasting is a service which provides a
best effort delivery of an anycast datagram to at least one host,
preferably only one host, which serves the anycast address.
definition makes clear that anycast datagrams receive the same
type of service as IP datagrams. And while the definition
delivery to multiple hosts, it makes clear that the goal is
to just one host
Anycast
There appear to be a number of ways to support anycast addresses
some of which use small pieces of the existing address space,
of which require that a special class of IP addresses be assigned
The major advantage of using the existing address space is that
may make routing easier. As an example, consider a situation where
portion of each IP network number can be used for anycasting. I.e.,
a site, if it desires, could assign a set of its subnet addresses
be anycast addresses. If, as some experts expect, anycast routes
treated just like host routes by the routing protocols, the
addresses would not require special advertisement outside the site --
the host routes could be folded in with the net route. (If
anycast addresses is supported by hosts outside the network,
those hosts would still have be advertised using host routes).
major disadvantages of this approach are (1) that there is no
way for stateful protocols like TCP to discover that an address is
anycast address, and (2) it is more difficult to support internet
wide well-known anycast address. The reasons TCP needs to know
an address is an anycast address is discussed in more detail below
The concern about well-known anycast addresses requires a bit
explanation. The idea is that the Internet might establish that
particular anycast address is the logical address of the DNS server
Then host software could be configured at the manufacturer to
send DNS queries to the DNS anycast address. In other words
anycasting could be used to support autoconfiguration of
resolvers
The major advantages of using a separate class of addresses are
it is easy to determine if an address is an anycast address
well-known anycast addresses are easier to support. The
disadvantage is that routing may be more painful, because the
protocols may have to keep track of more anycast routes
An intermediate approach is to take part of the current address
(say 256 Class C addresses) and make the network addresses
anycast addresses (and ignore the host part of the class C address).
The advantage of this approach is that it makes anycast routes
Partridge, Mendez & Milliken [Page 3]
RFC 1546 Host Anycasting Service November 1993
like network routes (which are easier for some routing protocols
handle). The disadvantages are that it uses the address
inefficiently and so more severely limits the number of
addresses that can be supported
In the balance it seems wiser to use a separate class of addresses
Carving anycast addresses from the existing address space seems
likely to cause problems in situations in which either
mistakenly fail to recognize anycast addresses (if anycasts are
of each site's address space) or use the address space
(if network addresses are used as anycast addresses). And
advantages of using anycast addresses for autoconfiguration
compelling. So this memo assumes that anycast addresses will be
separate class of IP addresses (not yet assigned). Since
anycast address is a virtual host address and the number
anycasting hosts seems unlikely to be larger than the number
services offered by protocols like TCP and UDP, the address
could be quite small, perhaps supporting as little as 2**16
addresses
Transmission and Reception of Anycast
Historically, IP services have been designed to work even if
are not present (e.g., on LANs without routers). Furthermore,
in the Internet community have historically felt that hosts
not have to participate in routing protocols to operate. (See,
instance, page 7 of STD 3, RFC 1122). To provide an
service that is consistent with these traditions, the handling
anycast addresses varies slightly depending on the type of network
which datagrams with anycast addresses are sent
On a shared media network, such as an Ethernet and or Token Ring,
must be possible to transmit an anycast datagram to a server also
the same network without consulting a (possibly non-existent) router
There are at least two ways this can be done
One approach is to ARP for the anycast address. Servers
support the anycast address can reply to the ARP request, and
sending host can transmit to the first server that responds.
approach is reminiscent of the ARP hack (RFC 1027) and like the
hack, requires ARP cache timeouts for the anycast addresses be
small (around 1 minute), so that if an anycast server goes down
hosts will promptly flush the ARP entry and query for other
supporting the anycast address
Another approach is for hosts to transmit anycast datagrams on
link-level multicast address. Hosts which serve an anycast
would be expected to listen to the link-level multicast address
Partridge, Mendez & Milliken [Page 4]
RFC 1546 Host Anycasting Service November 1993
datagrams destined for their anycast address. By multicasting on
local network, there is no need for a router to route the
datagrams. One merit of this approach is that if there are
servers and one goes down, the others will still receive
requests. Another possible advantage is that, because anycast
entries must be quickly timed out, the multicasting approach may
less traffic intensive than the ARP approach because in the
approach, transmissions to an anycast address are likely to cause
broadcast ARP, while in the multicast approach, transmissions
only to a select multicast group. An obvious disadvantage is that
there are multiple servers on a network, they will all receive
anycast message, when delivery to only one server was desired
On point-to-point links, anycast support is simpler. A single
of the anycast datagram is forwarded along the appropriate
towards the anycast destination
When a router receives an anycast datagram, the router must decide
it should forward the datagram, and if so, transmits one copy of
datagram to the next hop on the route. Note that while we may
that a router will always know the correct next hop for an
datagram and will not have to multicast anycast datagrams on a
network, there are probably situations in which there are
servers on a local network, and to avoid sending to one that
recently crashed, routers may wish to send anycast datagrams on
link-level multicast address. Because hosts may multicast
datagrams, routers should take care not to forward a datagram if
believe that another router will also be forwarding it
Hosts which wish to receive datagrams for a particular
address will have to advertise to routers that they have joined
anycast address. On shared media networks, the best mechanism
probably for a host to periodically multicast information about
anycast addresses it supports (possibly using an enhanced version
IGMP). The multicast messages ensure that any routers on the
hear that the anycast address is supported on the local subnet
can advertise that fact (if appropriate) to neighboring routers
Note that if there are no routers on the subnet, the
messages would simply simply ignored. (The multicasting approach
suggested because it seems likely to be simpler and more
than developing a registration protocol, in which an anycast
must register itself with each router on its local network).
On point-to-point links, a host can simply advertise its
addresses to the router on the other end of the link
Observe that the advertisement protocols are a form of
protocol and that it may make sense to simply require anycast
Partridge, Mendez & Milliken [Page 5]
RFC 1546 Host Anycasting Service November 1993
to participate (at least partly) in exchanges of regular
messages
When a host receives an IP datagram destined for an anycast
it supports, the host should treat the IP datagram just as if it
destined for one of the host's non-anycast IP addresses. If the
does not support the anycast address, it should silently discard
datagram
Hosts should accept datagrams with an anycast source address
although some transport protocols (see below) may refuse to
them
How UDP and TCP Use
It is important to remember that anycasting is a stateless service
An internetwork has no obligation to deliver two successive
sent to the same anycast address to the same host
Because UDP is stateless and anycasting is a stateless service,
can treat anycast addresses like regular IP addresses. A
datagram sent to an anycast address is just like a unicast
datagram from the perspective of UDP and its application. A
datagram from an anycast address is like a datagram from a
address. Furthermore, a datagram from an anycast address to
anycast address can be treated by UDP as just like a unicast
(although the application semantics of such a datagram are a
unclear).
TCP's use of anycasting is less straightforward because TCP
stateful. It is hard to envision how one would maintain TCP
with an anycast peer when two successive TCP segments sent to
anycast peer might be delivered to completely different hosts
The solution to this problem is to only permit anycast addresses
the remote address of a TCP SYN segment (without the ACK bit set).
TCP can then initiate a connection to an anycast address. When
SYN-ACK is sent back by the host that received the anycast segment
the initiating TCP should replace the anycast address of its peer
with the address of the host returning the SYN-ACK. (The
TCP can recognize the connection for which the SYN-ACK is destined
treating the anycast address as a wildcard address, which matches
incoming SYN-ACK segment with the correct destination port
address and source port, provided the SYN-ACK's full address
including source address, does not match another connection and
sequence numbers in the SYN-ACK are correct.) This approach
that a TCP, after receiving the SYN-ACK is always communicating
only one host
Partridge, Mendez & Milliken [Page 6]
RFC 1546 Host Anycasting Service November 1993
Applications and
In general, applications use anycast addresses like any other
address. The only worrisome application use of anycasting
applications which try to maintain stateful connections over UDP
applications which try to maintain state across multiple
connections. Because anycasting is stateless and does not
delivery of multiple anycast datagrams to the same system,
application cannot be sure that it is communicating with the
peer in two successive UDP transmissions or in two successive
connections to the same anycast address
The obvious solutions to these issues are to require
which wish to maintain state to learn the unicast address of
peer on the first exchange of UDP datagrams or during the first
connection and use the unicast address in future conversations
Anycasting and
It has often been suggested that IP multicasting can be used
resource location, so it is useful to compare the services offered
IP multicasting and IP anycasting
Semantically, the difference between the two services is that
anycast address is the address of a single (virtual) host and
the internetwork will make an effort to deliver anycast datagrams
a single host. There are two implications of this difference
First, applications sending to anycast addresses need not worry
managing the TTLs of their IP datagrams. Applications
multicast to find a service must balance their TTLs to maximize
chance of finding a server while minimizing the chance of
datagrams to a large number of servers it does not care about
Second, making a TCP connection to an anycast address makes
good sense, while the meaning of making a TCP connection to
multicast address are unclear. (A TCP connection to a
address is presumably trying to establish a connection to
peers simultaneously, which TCP is not designed to support).
From a practical perspective, the major difference between
and multicasting is that anycasting is a special use of
addressing while multicasting requires more sophisticated
support. The important observation is that multiple routes to
anycast address appear to a router as multiple routes to a
destination, and the router can use standard algorithms to choose
the best route
Partridge, Mendez & Milliken [Page 7]
RFC 1546 Host Anycasting Service November 1993
Another difference between the two approaches is that
location using multicasting typically causes more datagrams to
sent. To find a server using multicasting, an application
expected to transmit and retransmit a multicast datagram
successively larger IP TTLs. The TTL is initially kept small to
to limit the number of servers contacted. However, if no
respond, the TTL must be increased on the assumption that
available servers (if any) were farther away than was reachable
the initial TTL. As a result, resource location using
causes one or more multicast datagrams to be sent towards
servers, with some datagrams' TTLs expiring before reaching a server
With anycasting, managing the TTL is not required and so (
the case of loss) only one datagram need be sent to locate a server
Furthermore, this datagram will follow only a single path
A minor difference between the two approaches is that anycast may
less fault tolerant than multicast. When an anycast server fails
some datagrams may continue to be mistakenly routed to the server
whereas if the datagram had been multicast, other servers would
received it
Related
The ARPANET AHIP-E Host Access Protocol described in RFC 878
logical addressing which allows several hosts to share a
logical address. This scheme could be used to support
within a PSN subnet
Security
There are at least two security issues in anycasting, which
simply mentioned here without suggested solutions
First, it is clear that malevolent hosts could volunteer to serve
anycast address and divert anycast datagrams from legitimate
to themselves
Second, eavesdropping hosts could reply to anycast queries
inaccurate information. Since there is no way to verify
in an anycast address, there is no way to detect that
eavesdropping host is not serving the anycast address to which
original query was sent
Partridge, Mendez & Milliken [Page 8]
RFC 1546 Host Anycasting Service November 1993
This memo has benefitted from comments from Steve Deering,
Francis, Christian Huitema, Greg Minshall, Jon Postel,
Ramanathan, and Bill Simpson. However, the authors are
responsible for any dumb ideas in this work
Authors'
Craig
Bolt Beranek and
10 Moulton
Cambridge MA 02138
EMail: craig@bbn.
Trevor
Bolt Beranek and
10 Moulton
Cambridge MA 02138
EMail: tmendez@bbn.
Walter
Bolt Beranek and
10 Moulton
Cambridge MA 02138
EMail: milliken@bbn.
Partridge, Mendez & Milliken [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
