RFC 1546

Host Anycasting Service

📅 published November 1993, from ietf

RFC 1546: Host Anycasting Service 🎀

Okay bestie, here's the title block tea ☕. This one is from the Network Working Group and was written by C. Partridge, T. Mendez, and W. Milliken from BBN 🦋. It's Category: Informational and it's dated November 1993 🌸. The title block doesn't list any documents it obsoletes or updates, so there's nothing to chase there ✨.

  • Request for Comments: 1546
  • Title: Host Anycasting Service
  • Authors: C. Partridge, T. Mendez, W. Milliken (BBN)
  • Category: Informational
  • Date: November 1993
  • Obsoletes / Updates: none listed in the title block

Status of this Memo 💅

This memo gives information to the Internet community 💖. It does not specify an Internet standard of any kind 🙈. Distribution of this memo is unlimited 🌈.

Abstract ✨

Okay so this RFC describes an internet anycasting service for IP 🌸. Its main job is to pin down what anycasting means inside an IP internet 🧚. As much as possible, it stays neutral about how the internetwork actually makes that happen 🫶. Also, it describes an experimental service and does not propose a protocol 🙈. The Internet Research Task Force (IRTF) is the group that produced this memo 👑.

Motivation 💖

Picture this: there are tons of situations where a host, an app, or a user wants to find a host that offers some service. If several servers offer that service, they don't really care which one they land on 🍓. Anycasting is an internetwork service built for exactly this need 🦋. A host sends a datagram to an anycast address, and the internetwork is responsible for best effort delivery of that datagram to at least one of the servers that accept datagrams for that anycast address, and ideally just one of them 🔥.

The whole point is that it makes finding a server way easier 💅. Instead of checking a list of archie servers and picking the closest one yourself, you could literally just type:

telnet archie.net

and you'd be connected to the nearest archie server 😭. DNS resolvers wouldn't need to be set up with the IP addresses of their servers anymore. They could just send a query to a well-known DNS anycast address 🧚. Mirrored FTP sites could share one anycast address too, so users could simply FTP to that address to reach the nearest server 🌈.

Architectural Issues 🎀

Adding anycasting to IP's lineup means making some decisions about balancing IP's architectural requirements with what anycasting needs ✨. This section works through those issues 💜.

The first and most critical issue is how to balance IP's stateless service with the wish for an anycast address to represent a single virtual host 👑. Two examples make this way clearer. In both, hosts X and Y serve an anycast address, and another host, Z, uses that anycast address to contact a service 🫶.

In the first example, Z sends a UDP datagram to the anycast address. Since an anycast address is logically treated as one virtual host, should the datagram be delivered to both X and Y? The answer is yes, delivery to both X and Y is permissible 😭. IP is allowed to duplicate and misroute datagrams, so there are definitely scenarios where one datagram could end up at both X and Y 💀. So in an IP environment, anycasting means IP gives best effort delivery of an anycast datagram to one, but possibly more than one, of the hosts serving that anycast address 💅.

In the second example, Z sends two datagrams to the anycast address. The first one gets delivered to X. Which host gets the second one, X or Y? It would be convenient for stateful protocols like TCP if all of a connection's datagrams went to the same host 🥺. But IP is stateless (so it can't remember where earlier datagrams went), and one goal of anycasting is to support replicated services 🍓. So the second datagram can be delivered to either X or Y 🙈. Stateful protocols will have to employ some extra mechanism to make sure later datagrams reach the same host 🔥. Suggestions for how TCP can do that are discussed below 🦋.

After looking at both examples, the correct definition of IP anycasting is a stateless best effort delivery service that delivers an anycast datagram to at least one host, and ideally only one host, serving the anycast address 🌸. This means anycast datagrams get the same basic type of service as regular IP datagrams ✨. And even though the definition allows delivery to multiple hosts, the goal is clearly delivery to just one 👑.

Anycast Addresses 🧚

There seem to be a number of ways to support anycast addresses 🌈. Some use small pieces of the existing address space, and others need a special class of IP addresses to be assigned 💖.

The big advantage of using existing address space is that it may make routing easier 🦋. For example, picture a situation where a portion of each IP network number is used for anycasting. In other words, a site could, if it wanted, assign a set of its subnet addresses to be anycast addresses 🫶. If, as some experts expect, anycast routes are treated just like host routes by routing protocols, the anycast addresses wouldn't need special advertisement outside the site, because the host routes could be folded in with the net route ✨. (If the anycast address is supported by hosts outside the network, those hosts would still have to be advertised using host routes.) 🙈

The major disadvantages of this approach are (1) there's no easy way for stateful protocols like TCP to discover that an address is an anycast address, and (2) it's harder to support an internet-wide well-known anycast address 😭. The reasons TCP needs to know this are discussed in more detail below 🔥. The well-known anycast concern needs a bit of explaining 💅. The idea is that the Internet might establish that a particular anycast address is the logical address of the DNS server. Then host software could be configured by the manufacturer to always send DNS queries to the DNS anycast address. In other words, anycasting could be used to support autoconfiguration of DNS resolvers 🎀.

The major advantages of using a separate class of addresses are that it's easy to tell whether an address is an anycast address, and well-known anycast addresses are easier to support 👑. The key disadvantage is that routing may be more painful, because the routing protocols may have to keep track of more anycast routes 💀.

An intermediate approach is to take part of the current address space (say 256 Class C addresses) and make the network addresses into anycast addresses, ignoring the host part of the Class C address 🍓. The advantage is that this makes anycast routes look like network routes, which are easier for some routing protocols to handle 🌸. The disadvantages are that it uses the address space inefficiently, so it more severely limits the number of anycast addresses that can be supported 😭.

In the balance, it seems wiser to use a separate class of addresses 🫶. Carving anycast addresses out of the existing address space seems more likely to cause problems, either because applications might mistakenly fail to recognize anycast addresses (if anycasts are part of each site's address space), or because the address space gets used inefficiently (if network addresses are used as anycast addresses) 🙈. Plus, the advantages of using anycast addresses for autoconfiguration seem compelling 🌈. So this memo assumes that anycast addresses will be a separate class of IP addresses (not yet assigned) 💅. Since each anycast address is a virtual host address, and the number of anycasting hosts seems unlikely to be larger than the number of services offered by protocols like TCP and UDP, the address space could be quite small, perhaps supporting as little as 2**16 different addresses 🧚.

Transmission and Reception of Anycast Datagrams ✨

Okay bestie, so historically IP services were designed to work even if routers aren't around, like on LANs with no routers 🏠. And a lot of the internet community has felt that hosts shouldn't have to take part in routing protocols just to operate 🙅‍♀️. (See, for instance, page 7 of STD 3, RFC 1122.) So to give anycasting a service that fits these traditions, the way anycast addresses are handled changes a little depending on the type of network the anycast datagrams are sent over 💅.

On a shared media network, such as an Ethernet and or Token Ring, it must be possible to send an anycast datagram to a server on the same network without checking with a router, which might not even exist 🧚. There are at least two ways this can be done.

One approach is to ARP for the anycast address 🔍. Servers that support the anycast address can reply to the ARP request, and the sending host can send to the first server that responds. This is kind of giving ARP hack (RFC 1027) energy, and just like the ARP hack, the ARP cache timeouts for the anycast addresses should be kept small (around 1 minute). That way, if an anycast server goes down, hosts will promptly flush the ARP entry and look for other servers that support the anycast address 🏃‍♀️💨.

Another approach is for hosts to send anycast datagrams to a link-level multicast address 📣. Hosts that serve an anycast address would be expected to listen on the link-level multicast address for datagrams destined for their anycast address. Since you're multicasting on the local network, a router doesn't need to route the anycast datagrams 🙌. One merit of this approach is that if there are multiple servers and one goes down, the others will still receive any requests. Another possible advantage is that anycast ARP entries have to time out quickly, so the multicast approach may be less traffic intensive than the ARP approach. In the ARP approach, sending to an anycast address is likely to cause a broadcast ARP, while in the multicast approach, transmissions only go to a select multicast group 🫶. An obvious disadvantage is that if there are multiple servers on a network, they will all receive the anycast message, even when delivery to only one server was desired 🙃.

On point-to-point links, anycast support is simpler 💖. A single copy of the anycast datagram is forwarded along the appropriate link toward the anycast destination.

When a router receives an anycast datagram, the router must decide whether it should forward the datagram. If so, it transmits one copy of the datagram to the next hop on the route 🧭. Now, we may hope that a router will always know the correct next hop for an anycast datagram and won't have to multicast anycast datagrams on a local network. But there are probably situations where there are multiple servers on a local network, and to avoid sending to one that has recently crashed, routers may wish to send anycast datagrams to a link-level multicast address 😬. Because hosts may multicast any datagrams, routers should take care not to forward a datagram if they believe that another router will also be forwarding it 🛑.

Hosts that want to receive datagrams for a particular anycast address will have to advertise to routers that they have joined the anycast address 📢. On shared media networks, the best mechanism is probably for a host to periodically multicast information about the anycast addresses it supports (possibly using an enhanced version of IGMP). These multicast messages make sure any routers on the network hear that the anycast address is supported on the local subnet, and they can advertise that fact (if appropriate) to neighboring routers 🗣️. Note that if there are no routers on the subnet, the multicast messages would simply be ignored. (This multicasting approach is suggested because it seems likely to be simpler and more reliable than developing a registration protocol, where an anycast server must register itself with each router on its local network 📝.)

On point-to-point links, a host can simply advertise its anycast addresses to the router on the other end of the link 🔗.

Observe that the advertisement protocols are a form of routing protocol, and it may make sense to simply require anycast servers to take part (at least partly) in exchanges of regular routing messages 🤓.

When a host receives an IP datagram destined for an anycast address it supports, the host should treat the IP datagram just as if it was destined for one of the host's non-anycast IP addresses 🎀. If the host does not support the anycast address, it should silently discard the datagram 🤫.

Hosts should accept datagrams with an anycast source address, although some transport protocols (see below) may refuse to accept them 🙈.

How UDP and TCP Use Anycasting 🌸

It's really important to remember that anycasting is a stateless service 🧠. An internetwork has no obligation to deliver two successive packets sent to the same anycast address to the same host. No promises, no cap 🤷‍♀️.

Because UDP is stateless and anycasting is stateless too, UDP can treat anycast addresses like regular IP addresses, and honestly that's iconic of it 🦋. A UDP datagram sent to an anycast address is just like a unicast UDP datagram from the perspective of UDP and its application. A UDP datagram from an anycast address is like a datagram from a unicast address. Furthermore, a datagram from an anycast address to an anycast address can be treated by UDP as just like a unicast datagram (although the application semantics of such a datagram are a bit unclear 🤔).

TCP's use of anycasting is less straightforward, because TCP is stateful 😭. It's hard to see how you'd maintain TCP state with an anycast peer when two successive TCP segments sent to the anycast peer might be delivered to completely different hosts 💀.

The solution to this problem is to only permit anycast addresses as the remote address of a TCP SYN segment (without the ACK bit set) ✨. A TCP can then start a connection to an anycast address. When the 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 initiating TCP can recognize the connection that the SYN-ACK is destined for by treating the anycast address as a wildcard address. That wildcard matches any incoming SYN-ACK segment with the correct destination port and address and source port, provided the SYN-ACK's full address, including source address, does not match another connection and the sequence numbers in the SYN-ACK are correct 🧩.) This approach ensures that a TCP, after receiving the SYN-ACK, is always communicating with only one host 👑.

Applications and Anycasting 💅

In general, applications use anycast addresses like any other IP address 💁‍♀️. The only worrisome application use of anycasting is applications that try to maintain stateful connections over UDP, and applications that try to maintain state across multiple TCP connections 😰. Because anycasting is stateless and does not guarantee delivery of multiple anycast datagrams to the same system, an application can't be sure that it's talking to the same peer in two successive UDP transmissions, or in two successive TCP connections to the same anycast address 🫠.

The obvious solutions to these issues are to require applications that want to maintain state to learn the unicast address of their peer during the first exchange of UDP datagrams, or during the first TCP connection, and then use that unicast address in future conversations 🎯.

Anycasting and Multicasting 🦋

It has often been suggested that IP multicasting can be used for resource location, so it's useful to compare the services offered by IP multicasting and IP anycasting 👀.

Semantically, the difference between the two services is that an anycast address is the address of a single (virtual) host, and the internetwork will make an effort to deliver anycast datagrams to a single host 🎯. There are two implications of this difference. First, applications sending to anycast addresses don't need to worry about managing the TTLs of their IP datagrams 🙌. Applications using multicast to find a service have to balance their TTLs to maximize the chance of finding a server, while minimizing the chance of sending datagrams to a large number of servers they don't care about 😩. Second, making a TCP connection to an anycast address makes perfectly good sense, while the meaning of making a TCP connection to a multicast address is unclear 🤨. (A TCP connection to a multicast address is presumably trying to establish a connection to multiple peers simultaneously, which TCP isn't designed to support 🙅‍♀️.)

From a practical perspective, the major difference between anycasting and multicasting is that anycasting is a special use of unicast addressing, while multicasting requires more sophisticated routing support 🧩. The important observation is that multiple routes to an anycast address appear to a router as multiple routes to a unicast destination, so the router can use standard algorithms to choose the best route 🛣️.

Another difference is that resource location using multicasting typically causes more datagrams to be sent 📈. To find a server using multicasting, an application is expected to transmit and retransmit a multicast datagram with successively larger IP TTLs. The TTL is initially kept small to try to limit the number of servers contacted. However, if no servers respond, the TTL must be increased on the assumption that the available servers (if any) were farther away than the initial TTL could reach 📏. As a result, resource location using multicasting causes one or more multicast datagrams to be sent toward multiple servers, with some datagrams' TTLs expiring before they reach a server 😵‍💫. With anycasting, managing the TTL isn't required, so (ignoring the case of loss) only one datagram needs to be sent to locate a server. And this datagram will follow only a single path 🎀.

A minor difference is that anycast may be less fault tolerant than multicast. When an anycast server fails, some datagrams may keep getting mistakenly routed to that server, whereas if the datagram had been multicast, other servers would have received it 🥲.

The ARPANET AHIP-E Host Access Protocol described in RFC 878 supports logical addressing, which allows several hosts to share a single logical address 🍓. This scheme could be used to support anycasting within a PSN subnet.

Security Considerations 🔐

⚠️ Bestie, read this part carefully. There are at least two security issues in anycasting. They're simply mentioned here, without suggested solutions 😱.

First, it's clear that malevolent hosts could volunteer to serve an anycast address and divert anycast datagrams from legitimate servers to themselves 👿.

Second, eavesdropping hosts could reply to anycast queries with inaccurate information. Since there's no way to verify membership in an anycast address, there's no way to detect that the eavesdropping host isn't serving the anycast address the original query was sent to 🕵️‍♀️💀.

Acknowledgements 🫶

This memo has benefitted from comments from Steve Deering, Paul Francis, Christian Huitema, Greg Minshall, Jon Postel, Ram Ramanathan, and Bill Simpson 🌈. However, the authors are solely responsible for any dumb ideas in this work 💜.

Authors' Addresses ✨

okay the squad behind this one 🫶 here's how to reach each of them, bestie:

Craig Partridge
Bolt Beranek and Newman
10 Moulton St
Cambridge MA 02138

EMail: craig@bbn.com
Trevor Mendez
Bolt Beranek and Newman
10 Moulton St
Cambridge MA 02138

EMail: tmendez@bbn.com
Walter Milliken
Bolt Beranek and Newman
10 Moulton St
Cambridge MA 02138

EMail: milliken@bbn.com

all three of them are at Bolt Beranek and Newman, same address, same main character energy 💅🌸

📦 where this page comes from