Summary

  • RFC 2373 allocated anycast from ordinary unicast address space; the bits did not announce that several interfaces shared the address or identify the interface routing would select.
  • “Nearest” meant nearest under the routing protocols' current measure of distance, not geographically closest, fastest, healthiest, least loaded or stable across time.

One address, no winner encoded

RFC 2373 began its IPv6 addressing model with interfaces. A unicast address identified one interface. A multicast address identified a set and asked delivery to all of them. Anycast also identified a set, but delivery went to one interface—the “nearest” according to the routing protocols' measure of distance.

The decisive design choice was what the address did not contain. Anycast addresses were allocated from unicast space and used unicast formats. They were syntactically indistinguishable from unicast. When the same unicast-shaped address was assigned to several interfaces, the participating nodes had to be explicitly configured to know that it was anycast.

An address printed in a log therefore could not answer the most tempting questions. It did not say whether one interface or a set owned the destination. It did not name the member that would answer. It did not preserve a record of why routing selected that member.

“Nearest” belonged to routing

The quotation marks around “nearest” mattered. Distance was whatever the active routing protocols measured after policy, topology and current advertisements had done their work. The word did not mean shortest geographic distance. It did not mean lowest application latency, smallest queue, healthiest process or least loaded machine.

This made anycast useful without inventing a new packet field. Ordinary forwarding could direct traffic toward one member of the set. It also meant the selected member could change as routes changed. Two observers using the same destination address could reach different interfaces, and one observer could reach a different interface later. The stable string was a service rendezvous, not a stable machine name.

The route carried the hidden membership

RFC 2373 described a longest prefix P containing the topological region in which all members of an anycast set resided. Inside P, every member had to appear as a separate routing entry—a host route. Outside P, the address could be aggregated into the route for P.

That arrangement exposed the scaling price. If the members shared no useful topological region, P could be the null prefix and the separate route would need to exist throughout the Internet. The RFC called this a severe limit and expected global anycast sets to be unavailable or tightly restricted.

The address alone carried none of that membership ledger. Operators created it through interface configuration and route advertisements. Aggregation could deliberately hide the individual members from remote routing tables while still making one of them reachable.

A zero interface identifier could mean “one router”

The required Subnet-Router anycast address made the ambiguity concrete. It combined a subnet prefix with an all-zero interface identifier. On the wire it was syntactically the same as a unicast address for an interface numbered zero. Operationally, all routers on the subnet had to recognize it, and a packet was delivered to one of them.

RFC 2373 instructed implementations to treat other addresses as unicast unless specifically configured as anycast. Classification therefore lived partly outside the 128 bits. The same notation could acquire a different delivery meaning through configured membership and forwarding state.

Early restrictions recorded uncertainty

The document said there was little experience with widespread arbitrary Internet anycast and known hazards in using it fully. It temporarily prohibited anycast as a source address and limited assignment to routers. Later IPv6 addressing specifications removed those early restrictions while preserving the central syntax and route-selection model.

That evolution should not be flattened. The 1998 rules show a minimum initial specification: reuse familiar address formats and routing, deploy a required router case, and constrain the unknown surface while experience accumulates. Later permission is not evidence that every earlier hazard had already been solved, nor that RFC 2373 described modern service operations.

What a reply could and could not prove

A returned packet could show that some path reached some responding member at that moment. It could not, by itself, identify all members, prove the route was optimal, show that health checks selected the instance, guarantee the next packet would reach the same place or establish that the application completed correctly.

The useful evidence chain kept separate records: the destination string; the configured anycast membership; each route advertisement; the observer's selected path; the interface that received the packet; the process that answered; any session state; and the application result.

Lu Heng's running-code principle puts authority in the configuration and forwarding that actually operate, not in an address label. Minimum initial specification explains why IPv6 reused unicast syntax instead of creating a self-describing anycast type. Reality layers supply the reporting rule: an address, a route, a response and a completed service action are adjacent facts, not one fact.

RFC 2373 made one address capable of finding one member of a set. Its achievement depended on refusing to pretend that the address knew which member that would be.