Das Abschiedspaket bat alle zu vergessen. Es bewies keine Löschung: RFC 1868

Zusammenfassung

• RFC 1868 behandelte eine Proxy-ARP-Lücke: Ein Einwahlhost konnte den ersten Kommunikationsserver verlassen und über einen zweiten zurückkehren, bevor LAN-Nachbarn die Hardwareadresse des ersten aus ihrem Cache entfernten.
• UNARP verwendete eine unaufgeforderte ARP Reply mit Hardwareadresslänge null. Unterstützende Empfänger sollten den Eintrag für die Quell-IP löschen; unwissende Implementierungen sollten das verkürzte Paket ablehnen.
• Aussenden, Empfang, syntaktische Annahme, lokale Löschung, erneute Auflösung und erfolgreiche Weiterleitung waren verschiedene Ereignisse. Für die Schritte hinter der Übertragung gab es keine Quittung.

Ein gültiger Eintrag zeigte auf die vergangene Sitzung

Ein entfernter Rechner wählt sich zunächst über CS1 in einen gemeinsam genutzten Modempool ein. Für Host A im LAN scheint seine IP-Adresse direkt benachbart zu sein, obwohl der Rechner hinter einem Kommunikationsserver sitzt. Fragt Host A per ARP nach dem Ziel, antwortet CS1 stellvertretend mit seiner eigenen Hardwareadresse. Host A speichert diese Zuordnung und sendet spätere Frames an CS1.

Der RFC 1027 beschrieb Proxy ARP als Kompatibilitätsmittel. Ein Gateway konnte ein verborgenes Subnetz vertreten, ohne dass alte Hosts eine neue Route oder die tatsächliche Topologie kennen mussten. Der Preis war eine starke Verdichtung: Die Erreichbarkeit eines fernen Rechners erschien lokal als IP-zu-Hardware-Zuordnung des Vermittlers.

Trennt sich der Nutzer und kehrt noch vor Ablauf dieses Eintrags über CS2 zurück, bleibt die IP gleich, während sich der zuständige Vermittler ändert. Host A besitzt keine syntaktisch beschädigte Information. Es besitzt eine zeitlich überholte. Bis zur Korrektur gehen seine Frames weiter an CS1.

Die Nachbartabelle gehörte jedem Host selbst

ARP wurde im RFC 826 als Verfahren zur Verteilung von Zuordnungen zwischen Protokoll- und lokalen Hardwareadressen beschrieben. Eine Request stellt eine Frage. Eine Reply liefert eine Absenderzuordnung, die der Empfänger in seine eigene Tabelle übernehmen und für spätere Übertragungen nutzen kann.

Diese Tabellen bilden kein gemeinsames, atomar bestätigtes Register. Jeder Rechner verwaltet seinen Ausschnitt nach eigener Zeit und eigener Beobachtung. Nach einer Bewegung können deshalb mehrere Altersstufen derselben Wahrheit gleichzeitig existieren.

Der RFC 1122 verlangte einen Mechanismus zur Ungültigerklärung alter ARP-Einträge und nannte Zeitablauf, Unicast-Abfrage, Hinweise der Sicherungsschicht sowie Hinweise höherer Schichten nach Zustellproblemen. Die Verfahren durften zusammenwirken, lieferten aber verschiedene Belege. Ein Ablauf belegt lokale Vorsicht, eine ausgebliebene Antwort eine fehlende Reaktion, ein Link-Hinweis einen nahen Fehler und eine Meldung von oben eine andere beobachtete Folge. Keines nennt automatisch CS2 als neue Tür.

Null Byte Hardwareadresse bedeutete negative Information

Der im November 1995 als Experimental veröffentlichte RFC 1868 wählte einen eng begrenzten Eingriff. UNARP behielt den Opcode 2 einer ARP Reply, den IPv4-Protokolltyp und die Protokolladresslänge vier. Die Hardwareadresslänge wurde null. Als Quell-Protokolladresse stand die IP des abgehenden Hosts, als Ziel 255.255.255.255. Weil Quell- und Ziel-Hardwarefelder entfielen, umfasste die Nachricht vor dem Link-Header sechzehn Byte.

Ein kompatibler Empfänger sollte den zur Quell-IP gehörenden Cache-Eintrag löschen. Der Server musste nicht einmal festhalten, ob er zuvor selbst eine Proxy-ARP-Antwort gesendet hatte. Er durfte bei jeder Trennung ein UNARP ausgeben. Ebenso konnte sich ein Host bei geordnetem Verlassen des LAN selbst abmelden.

Die Logik beruhte auf ungleichen Fehlerkosten. Eine überflüssige Löschung verursachte eine spätere Neuanfrage. Das Beibehalten der falschen Adresse leitete weitere Frames zum alten Server. Lieber sollte eine Frage wieder offen werden, als eine falsche Antwort als Kontinuität fortbestehen.

Die Löschung enthielt jedoch keinen neuen Standort. Host A musste danach erneut fragen, CS2s Antwort empfangen, die neue Hardwareadresse lernen und Daten über sie senden. Nicht mehr an CS1 zu glauben bewies noch keine Erreichbarkeit über CS2.

Ablehnung war Teil der Übergangsordnung

Die Länge null sollte unterstützende und ältere Implementierungen unterscheiden. Eine herkömmliche ARP-Software, die UNARP nicht verstand, sollte die verkürzte Reply als ungültig verwerfen, statt eine Nulladresse einzutragen. Gemischte Unterstützung war damit kein Sonderfall, sondern die erwartete Umgebung.

Zusätzlich empfahl der Text einen Konfigurationsschalter zum Abschalten, falls vorhandene Herstellerimplementierungen auf das Format problematisch reagierten. Ein Host konnte die Funktion also kennen und trotzdem verweigern. Das veröffentlichte Dokument schuf eine gemeinsame Möglichkeit, aber keine gemeinsame laufende Realität.

Für den Sender besaß Schweigen mehrere Bedeutungen. Der Empfänger konnte das Paket erhalten und löschen, erhalten und verwerfen, es gar nicht erhalten, die Funktion abgeschaltet oder keinen passenden Eintrag haben. Eine Quittungsliste existierte nicht. Auch die Erwartung breiter Unterstützung blieb eine Aussage des Memos und keine Erhebung installierter Systeme.

Wiederholung verringerte Verlust, nicht die Beweislast

Der RFC 2176 definierte 1997 eine verwandte UNARP-Variante für IPv4 über MAPOS. Sie erhielt einen eigenen Operationscode und echte Hardwarefelder. Ein neu aktiver Knoten sendete drei Meldungen im Abstand von dreißig Sekunden. Empfänger löschten eine IP-Zuordnung nur, wenn die mitgesendete Hardwareadresse vom Cachewert abwich.

Drei Sendungen senkten die Wahrscheinlichkeit, dass ein verlorener Frame den alten Zustand konservierte. Der Vergleich schützte einen bereits richtigen Eintrag. Trotzdem waren drei Sendungen keine drei Empfangsbestätigungen. Der RFC verlangte separat Cache-Alterung und sofortiges Leeren bei Linkverlust. Mehrere unabhängige Mechanismen trugen die Korrektur.

Der RFC 3790 ordnete RFC 1868 später als IPv4-abhängige Erweiterung zum Entfernen von ARP-Cache-Einträgen ein. Diese Einordnung belegt Zweck und Dokumentgeschichte, nicht Verbreitung oder Wirkung.

Auch die neue Behauptung blieb kleiner als der Dienst

Der RFC 5227 erklärte später die beiden Aussagen in einer ARP Request: Die Absenderfelder behaupten eine Zuordnung, die Zielfelder stellen eine Frage. Ein Probe fragt nach bestehender Nutzung und deutet eine eigene Nutzungsabsicht an. Ein Announcement erklärt, dass der Absender die Adresse jetzt verwendet.

UNARP sprach in die Gegenrichtung: Vertraut der alten Zuordnung nicht mehr. Positive wie negative Aussagen sind Eingaben für lokale Empfänger, die Syntax, Konfiguration und eigenen Zustand prüfen. Keine davon beweist allein globale Übereinstimmung, Konfliktfreiheit, Zustellung des nächsten Frames oder Erfolg der Anwendung.

Die historische Konsequenz ist kein Ruf nach einer zentralen ARP-Autorität. Sie ist eine Forderung nach präzisen Belegnamen. „Abschied gesendet“, „Frame an diesem Messpunkt gesehen“, „Eintrag auf diesem Host gelöscht“, „neue Zuordnung gelernt“ und „Daten erfolgreich weitergeleitet“ reichen jeweils so weit wie ihr Zeuge. „Das Netz hat vergessen“ reicht weiter als das Paket.

Quellen und Grenzen

RFC 826, 1027 und 1122 liefern die Grundlagen zu ARP, Proxy ARP und Cache-Invalidierung. RFC 1868 definiert die experimentelle Nachricht; RFC 2176 zeigt die spätere Link-Variante; RFC 3790 klassifiziert die IPv4-Abhängigkeit; RFC 5227 erläutert Probe und Announcement. Diese Primärquellen belegen Formate, Sollverhalten und dokumentierte Erwartungen. Sie belegen keine heutige Verbreitung, allgemeine Produktkonformität, einen benannten Angriff oder Vorfall und keine erfolgreiche Zustellung in einem realen Netz.