Summary

  • RFC 1546 defined an anycast address as a way to reach at least one server for a service, not as the durable identity of the server that answered.
  • The same destination could select a different host on the next datagram, so state, instance identity, replica coherence and authentication needed evidence beyond the address.
  • Later RFCs refined the vocabulary and operating practice, but preserved the original boundary between a service locator and an accountable responder.

The address on the envelope

The familiar Internet story begins with an address that identifies where a packet should go. RFC 1546 began with a different question. Suppose a user needed a service but did not care which member of a group supplied it. Must the user first discover a particular host, or could the internetwork accept an address for the service and choose a suitable server?

Craig Partridge, Trevor Mendez and Walter Milliken published their answer in November 1993. The memo was Informational, originated in the IRTF and described an experimental service rather than an Internet standard. That status matters. It records an architectural proposal and its semantics; it does not prove universal implementation, operational success or deployment by any named network.

The proposed goal was deliberately qualified: deliver a datagram to at least one, and preferably only one, host accepting the anycast address. “Preferably” carries much of the history. Ordinary IP could duplicate or misroute a datagram. The service could aim for one recipient without turning that aim into an exactly-once receipt.

This was a narrow common contract. The address said, in effect, “one acceptable provider of this service.” It did not say which machine would receive the packet, what data that machine held, whether it was healthy, or whether it was entitled to speak for the service. Routing supplied selection, not identity.

The second datagram breaks the illusion

RFC 1546 tested the abstraction with a simple sequence. A first datagram sent to an anycast address might reach server X. A second datagram bearing the identical destination might reach X again, or it might reach server Y. IP kept no memory that X had been selected before.

That example is more revealing than a map of nearby replicas. It separates a label that remains constant from a relationship that may change between packets. Once an application carries state across requests, the distinction becomes operational. A challenge stored by X is no help if the reply reaches Y. A transaction partly recorded by one replica cannot be assumed to exist at another. A retry that is not idempotent may produce the effect twice if the first result was merely unseen rather than absent.

The packet path also does not promise single delivery. If a datagram can reach more than one server, “I sent one request” is not evidence that one server acted once. The address is therefore one item in an evidence chain, not a compressed proof of delivery, affinity and effect.

TCP had to change the referent

Connection-oriented transport exposed the same problem sharply. RFC 1546 proposed that an anycast address be permitted as the remote address only for an initial TCP SYN without ACK. When a server answered with a SYN-ACK from its unicast address, the initiator would replace the anycast peer with that unicast address. The conversation would begin by asking for any suitable service instance and continue by referring to one host.

The elegance lies in the transition. The first address performs discovery; the response establishes a more specific referent. Continuity does not emerge because the anycast address became a host identifier. It emerges because the connection stops using it as one.

The historical source does not establish that this special behavior was universally implemented. Later analysis in RFC 7094 described it as the original proposal and noted the broader transport hazard: if routing moves packets in a live transaction to an end system without the transaction state, the session can reset. A laboratory topology in which paths remain stable is not evidence that the same application will retain affinity under different global routing conditions.

RFC 1546 gave similar advice to applications using UDP or multiple TCP connections. If future exchanges required the same peer, the application could learn a unicast address during the first exchange. Again the design acquired continuity through an explicit instance reference, not through faith in the service address.

Locator, node and answering instance

RFC 2101 later put the distinction into the language of identifiers and locators. An anycast address could locate one member of a functionally equivalent group, but could never uniquely identify a host. Its useful temporal uniqueness might be shorter than the time required to establish a TCP connection.

Operational practice then needed names for the separate things hidden behind “the anycast server.” RFC 4786 called the shared IP a Service Address. An Anycast Node was one or more hosts and routers at a discrete location presenting a route to it. A catchment described the sources that routing would direct to a node under particular conditions. These objects were related, not interchangeable.

The routing system selected a path using topology and the request's origin. It did not certify geographic nearness, lowest latency or service quality. Equal-cost forwarding could even distribute packets in one transaction across paths leading to different nodes. A stable destination field would remain visible while the placement needed for stateful service disappeared.

Health was another independent layer. RFC 4786 described close coupling between service health and route advertisement as desirable where practical. But an advertised path does not itself prove that the application is serving correct data. RFC 3258's shared-unicast DNS guidance shows the trade-off. Operators had to coordinate zone distribution and switchovers, and a server receiving bad data should stop answering. Yet withdrawing a route whenever one DNS process failed was not generally recommended there, because reliable coupling added complexity and DNS could fail over among other addresses.

Reachability, process health and replica correctness were separate controls even when operators tried to align them.

A probe taken later is a different receipt

Anycast complicates observation as well as delivery. RFC 4892 noted that a ping, TCP connection, traceroute or later DNS query might not reach the DNS server that answered the request under investigation. A diagnostic performed afterward can describe the network at that later moment without identifying the earlier responder.

RFC 5001 addressed the narrower need with the EDNS Name Server Identifier option. A resolver could request an opaque value, and the server could place its chosen identifier inside the same DNS response. That improves attribution because the instance evidence travels with the answer being examined. Its authority remains bounded: NSID is server-defined and non-transitive. It does not authenticate an operator, establish a location, certify a dataset or prove what happened downstream.

The most defensible record therefore preserves multiple receipts: the configured Service Address, the route visible to the source, the response observed at a time, an in-response instance identifier where available, the transport outcome, the data version or validation result, the authentication evidence and the application's externally observable effect. Omitting those distinctions makes failover look like continuity and a locator look like an accountable identity.

The security warning was present at the beginning

RFC 1546 did not treat membership in an anycast set as self-authenticating. It warned that a malicious host could volunteer to serve the address and divert traffic, or that an eavesdropper could answer with inaccurate information. The routing or local delivery mechanism could choose a respondent while remaining unable to prove that respondent's authority.

This is the boundary that infrastructure automation still needs. A route can select where a packet goes. It cannot, by that fact alone, authorize the process, attest to the replica state or declare the application result successful. Those claims require their own mechanisms: authenticated protocols, signed data, consistency controls, transaction identifiers, logs and independent observation.

RFC 7094 preserved the practical consequence. Applications should assume that packets sent to the same anycast destination may reach different instances. The safest pattern is a self-contained one-packet request over a stateless transport, a reply to a unicast source, no hard server state between requests and idempotent retries. Where a multi-packet invocation is necessary, one anycast exchange can discover a unicast instance. The shared address starts selection; it does not finish attribution.

What the 1993 memo actually changed

RFC 7094 later called RFC 1546 the first formal specification of anycast and judged that its authors had captured most of the issues that persisted. The achievement was not a promise that one magic address would always find the fastest, safest or healthiest replica. It was a careful minimum specification: several implementations could coordinate around service-level addressing while transport and applications retained responsibility for continuity.

That economy created room for local routing systems, server designs and deployment models. It also made the evidence burden visible. The Service Address can remain the same while the selected route, node, process, dataset and operator change. The historical record proves the architecture and its warnings. It does not prove a named deployment, a vulnerability, an outage, an adoption rate, universal use of the proposed TCP transition or any quantified user impact.

The durable insight is almost grammatical. “This packet was sent to the same address” and “this packet reached the same server” are different sentences. RFC 1546 made it possible for the first to stay true while the second became unknowable without another receipt.

Sources