Zusammenfassung

  • RFC 1546 definierte eine Adresse, die mindestens einen Anbieter eines Dienstes erreichen sollte, möglichst nur einen, ohne einen bestimmten Server dauerhaft zu identifizieren.
  • Das zweite Datagramm konnte trotz gleicher Zieladresse bei einer anderen Instanz ankommen; Sitzungsbindung und genau einmalige Wirkung waren zusätzliche Anforderungen.
  • Spätere RFCs trennten Dienstadresse, Anycast-Knoten und Instanznachweis genauer, ohne Routingwahl mit Berechtigung oder Datenrichtigkeit gleichzusetzen.

Ein Dienst als Ziel

Craig Partridge, Trevor Mendez und Walter Milliken veröffentlichten RFC 1546 im November 1993. Das aus der IRTF stammende Dokument war Informational und beschrieb einen experimentellen Dienst, keinen Internetstandard. Es belegt eine veröffentlichte Architektur, nicht die flächendeckende Umsetzung oder den Einsatz bei einem bestimmten Betreiber.

Die Ausgangsfrage betraf Nutzer und Anwendungen, die eine Funktion suchten, aber keinen bestimmten Host verlangten. Wenn mehrere Server als gleichwertige Anbieter galten, konnte das Internetwork die Auswahl übernehmen. Ein Anycast-Datagramm sollte nach bestem Bemühen mindestens einen, vorzugsweise nur einen Server erreichen, der die Adresse akzeptierte.

Das Wort „vorzugsweise“ begrenzte das Versprechen. Gewöhnliches IP konnte Datagramme duplizieren oder fehlleiten. Ein gesendeter Auftrag bewies daher weder einen einzelnen Empfänger noch eine einmalige Ausführung. Die Adresse stellte die Dienstklasse dar; Route, Maschine, Prozesszustand und Berechtigung blieben andere Tatsachen.

Was das zweite Datagramm verändert

RFC 1546 wählte ein knappes Beispiel. Das erste Datagramm erreicht Server X. Beim zweiten mit demselben Ziel kann IP erneut X oder Server Y auswählen. Die IP-Schicht merkt sich die frühere Entscheidung nicht.

Für eine in sich geschlossene Abfrage kann das genau die gewünschte Freiheit sein. Für zustandsbehaftete Anwendungen ist es eine Bruchstelle. Y kennt eine bei X gespeicherte Herausforderung möglicherweise nicht. Eine auf X begonnene Transaktion muss bei Y nicht vorhanden sein. Wird ein Schreibvorgang nach ausbleibender Antwort wiederholt, beweist ein neuer Empfänger nicht, dass die erste Wirkung ausgeblieben ist.

Hinzu kommt, dass ein Datagramm mehr als einen Server erreichen konnte. Aus „einmal gesendet“ folgt nicht „einmal ausgeführt“. Ein belastbarer Befund muss Dienstadresse, Route zum gegebenen Zeitpunkt, erreichten Knoten, antwortende Instanz, Transportzustand, Replikatstand, Authentisierung und äußere Wirkung getrennt belegen.

TCP brauchte einen anderen Bezug

Für TCP schlug RFC 1546 einen expliziten Übergang vor. Nur der erste SYN ohne ACK sollte die Anycast-Adresse als entferntes Ziel verwenden. Der ausgewählte Server antwortete mit SYN-ACK von seiner Unicast-Adresse. Der Initiator ersetzte daraufhin die Anycast-Gegenstelle durch diese individuelle Adresse.

Der erste Schritt entdeckte irgendeinen geeigneten Anbieter; die Verbindung bezog sich anschließend auf genau diesen Host. Kontinuität entstand nicht, weil die gemeinsame Adresse zur Identität geworden wäre, sondern weil TCP sie nicht weiter als Identität verwendete. Die Quellen belegen den Vorschlag, nicht dessen universelle Implementierung.

RFC 7094 beschrieb später das allgemeine Transportrisiko: Verschiebt eine Routenänderung aktive Pakete zu einem Endsystem ohne den zugehörigen Zustand, kann die Sitzung zurückgesetzt werden. Ein Erfolg in einer Testumgebung mit stabilen Pfaden beweist keine Stabilität unter anderen globalen Routingbedingungen.

Auch UDP-Anwendungen oder mehrere TCP-Verbindungen mit gemeinsamem Zustand mussten eine Unicast-Adresse im ersten Austausch lernen, wenn sie denselben Partner erneut brauchten. Affinität wurde damit zu einer absichtlichen, beobachtbaren Entscheidung.

Service Address ist nicht Anycast Node

RFC 2101 schärfte die Unterscheidung zwischen Bezeichner und Lokator. Eine Anycast-Adresse konnte ein Mitglied einer funktional gleichwertigen Gruppe lokalisieren, aber nie einen Host eindeutig identifizieren. Ihre zeitliche Eindeutigkeit konnte kürzer sein als ein TCP-Verbindungsaufbau.

RFC 4786 gab den betrieblichen Gegenständen eigene Namen. Die Service Address ist die IP-Adresse des Dienstes. Ein Anycast Node umfasst Hosts und Router an einem diskreten Ort, die einen Pfad zu ihr anbieten. Das Catchment sind die Quellen, die unter einem bestimmten Routingzustand zu diesem Knoten gelangen. Topologie und Ursprung beeinflussen die Auswahl; sie garantieren weder geografische Nähe noch niedrigste Latenz oder höchste Qualität.

Paketweiser Lastausgleich über gleichwertige Wege kann sogar eine Transaktion auf verschiedene Knoten aufteilen. Die Zieladresse bleibt sichtbar gleich, während die für Zustand nötige Platzierung verloren geht.

Auch eine angekündigte Route beweist keinen gesunden Dienst. RFC 4786 hielt eine enge Kopplung von Dienstzustand und Routenankündigung für wünschenswert, soweit praktikabel. RFC 3258 zeigte beim Shared-Unicast-DNS die Kosten: Zonenverteilung und Umschaltung mussten koordiniert, ein Server mit falschen Daten musste stillgelegt werden. Ein Routenrückzug bei jedem DNS-Prozessfehler wurde dennoch nicht allgemein empfohlen, weil zuverlässige Kopplung komplex war und DNS andere Serveradressen nutzen konnte.

Die spätere Messung trifft womöglich eine andere Instanz

RFC 4892 warnte, dass Ping, TCP, Traceroute oder eine zusätzliche DNS-Abfrage nicht denselben Server erreichen müssen, der die untersuchte Antwort gab. Die spätere Probe ist ein neues Routingereignis.

RFC 5001 brachte Instanzinformation mit NSID in die betreffende DNS-Antwort. Ein Resolver fordert einen undurchsichtigen Wert an, den der Server selbst festlegt. Das ist stärker als eine nachträgliche Probe, bleibt aber nicht transitiv und nicht selbst authentisierend. NSID beweist weder Betreiber und Ort noch Datenrichtigkeit oder Anwendungswirkung.

Gute Beobachtung bewahrt deshalb Zeit, Route, Catchment, Antwort und Instanzhinweis zusammen mit Transportergebnis, Datenprüfung, Authentisierung und Anwendungsentscheidung auf. Jede Quittung besitzt nur die Aussagekraft ihrer eigenen Schicht.

Ein Freiwilliger war noch kein berechtigtes Mitglied

RFC 1546 warnte bereits davor, dass ein bösartiger Host sich freiwillig als Anbieter der Anycast-Adresse melden und Verkehr umleiten konnte. Ein Lauscher konnte mit falschen Informationen antworten. Die Zugehörigkeit war durch die Dienstadresse selbst nicht überprüfbar.

Routing bestimmt den Weg eines Pakets. Es ermächtigt den Prozess nicht, bescheinigt keinen Replikatstand und erklärt keinen Geschäftsvorgang für erfolgreich. Authentisierte Protokolle, Signaturen, Konsistenzprüfungen und Transaktionsbelege müssen diese Aufgaben separat erfüllen.

RFC 7094 empfahl, wechselnde Instanzen vorauszusetzen. Der sichere Fall besteht aus einer selbstständigen Ein-Paket-Anfrage, zustandslosem Transport, Antwort an eine Unicast-Quelle, keinem harten Zustand zwischen Anfragen und idempotenten Wiederholungen. Ein mehrteiliger Dienst kann Anycast zur Entdeckung und danach Unicast zur Bindung verwenden.

Die bleibende Leistung der schmalen Spezifikation

RFC 7094 bezeichnete RFC 1546 als erste formale Anycast-Spezifikation und urteilte, dass die Autoren die meisten fortbestehenden Probleme erfasst hatten. Sie versprachen nicht automatisch den nächsten, schnellsten, sichersten oder gesündesten Server. Sie legten nur den gemeinsamen Dienstbezug fest und ließen Kontinuität und Autorität bei Transport und Anwendung.

Die Quellen belegen diese Architekturgeschichte. Sie belegen keinen benannten Einsatz, Ausfall, Angriff, Verbreitungsgrad, universellen TCP-Mechanismus oder quantifizierten Schaden. Sicher ist die sprachliche Trennung: gleiche Adresse und gleicher Server sind verschiedene Aussagen. Wo das Protokoll nur die erste trägt, muss ein zusätzlicher Beleg die zweite tragen.

Quellen