Zusammenfassung

  • RFC 826 setzte nach der Routingentscheidung an. Ein Host kannte die unmittelbar anzusprechende Protokolladresse, brauchte für den Frame aber noch die Hardwareadresse auf dem gewählten lokalen Netz.
  • Die Broadcast-Anfrage fragte nach dem Ziel und legte zugleich die Absenderzuordnung offen. Der Empfänger lernte vor seiner Antwort; der lokale Cache machte die Beobachtung für weitere Frames ausführbar.
  • Cache-Ablauf, Proxy ARP und Konflikterkennung zeigten die Grenze: Eine Antwort kann ein Weiterleitungsversprechen statt Identität sein, und eine zugeteilte IP kann durch die Lage auf dem Link unbrauchbar werden.

Das fehlende Ziel hinter der Route

IP-Routing bestimmt Ausgangsschnittstelle und nächsten Protokoll-Hop. Ethernet verlangt danach eine 48-Bit-Adresse. Diese beiden Namen haben weder notwendigerweise dieselbe Länge noch eine ableitbare Beziehung.

RFC 826, im November 1982 von David C. Plummer veröffentlicht, stellte an diese Nahtstelle ein Address-Resolution-Modul. Es sucht das Paar aus Protokolltyp und Zieladresse in einer lokalen Übersetzungstabelle. Bei Treffer kann der Treiber senden; bei Fehlen fragt der Host auf dem durch Routing bereits bestimmten Segment.

Das Nachrichtenformat hält die Räume auseinander: Hardwaretyp, Protokolltyp, Adresslängen, Operation sowie Sender- und Zieladressen beider Arten. IPv4 über Ethernet wurde zum Standardfall, doch der Entwurf war allgemeiner. Er berechnete keine Wahrheit aus einer Adresse, sondern verteilte beobachtete Zuordnungen.

Für ein entferntes Ziel trägt das IP-Paket weiterhin die Serveradresse, während der erste Ethernet-Frame meist den Router nennt. ARP findet nicht den Gesamtpfad. Es vollzieht lokal einen Schritt, den Routing bereits gewählt hat.

Eine Frage an alle in der Nähe

Fehlt der Cache-Eintrag, sendet der Host seine eigenen Adressen und die gesuchte Protokolladresse als Broadcast. Alle Stationen hören die Anfrage; die erkannte Zielstation antwortet direkt.

Die Frage muss öffentlich sein, weil das Hardwareziel unbekannt ist. Der Antwortweg ist aus dem Request bekannt. RFC 826 vermied dagegen periodische Volltabellen-Ankündigungen: Die meisten Hosts würden viel nutzlosen Zustand sammeln und das Medium ständig belasten.

Die frühe Beschreibung durfte das auslösende IP-Paket verwerfen. RFC 1122 empfahl 1989, wenigstens das jüngste Paket je ungelöstem Ziel aufzubewahren. Das verbessert den Start, erhöht aber nicht die Beweiskraft der späteren Antwort.

RFC 1122 verlangte zudem Schutz gegen wiederholte Requests und empfahl höchstens einen pro Sekunde und Ziel. Schweigen beweist nicht eindeutig Abwesenheit; auch Verlust, Trennung oder Schlafzustand kommen infrage. Unbegrenztes Fragen vergrößert nur den Broadcast.

Lernen vor dem Opcode

Im Empfangsalgorithmus von RFC 826 wird zuerst die Senderzuordnung verarbeitet. Existiert seine Protokolladresse, ersetzt die neu beobachtete Hardwareadresse die alte. Ist der Empfänger das Ziel und fehlt der Eintrag, legt er ihn an. Erst danach prüft er, ob die Operation eine Antwort verlangt.

Der Request ist daher zugleich Frage und Aussage. Er sucht das Hardwareziel und teilt mit, wie man den Fragenden erreicht. Das Ziel lernt den Rückweg, bevor es antwortet; ein Monitor kann Zuordnungen beobachten, ohne das höhere Protokoll zu sprechen.

Aktualisierung hilft nach Umzug oder Interfacewechsel, zeigt aber den begrenzten Vertrauensrahmen. Die Nachricht authentifiziert den Sprecher nicht. Ein frischer Wert kann richtig, fehlerhaft oder gefälscht sein. Der Cache ist Arbeitswissen, kein Eigentumsregister.

RFC 826 diskutierte Alterung, schrieb sie aber nicht vor. RFC 1122 verlangte später einen Mechanismus zum Entfernen veralteter Einträge und konfigurierbare Timeouts, falls Zeit genutzt wird. Unicast-Prüfung sowie Hinweise von Link- oder höheren Schichten sind Alternativen. Gemeinsam verhindern sie, dass eine alte Beobachtung unbegrenzt Frames steuert.

Als ein Gateway für jemand anderen sprach

RFC 1027 dokumentierte 1987 Proxy ARP. Die University of Texas wollte ein großes Ethernet subnetzen, während viele Betriebssysteme Subnetze noch nicht verstanden. Gateways verbargen die Grenze.

Fragt A nach B auf einem anderen physischen Netz, kann ein Gateway mit Route zu B seine eigene Hardwareadresse zurückgeben. A sendet Frames an das Gateway, obwohl das enthaltene IP-Paket B nennt. Auf der Gegenseite kann dasselbe für den Rückweg geschehen.

Die Kompatibilität ersparte gleichzeitige Host-Updates. Die Antwort bedeutet aber nicht „Ich bin B“, sondern „Ich nehme B-Verkehr an und leite weiter“. Sie ist Delegation. Ihre Gültigkeit hängt von Route und Administration außerhalb von ARP ab.

Mehrere Proxies können antworten; die erste Nachricht kann den Cache gewinnen. Bei falscher Route gelingt die lokale Auflösung, während die Lieferung scheitert. Der Reply beweist weder Endpunktidentität noch physische Nähe.

Die Zuteilung, die der Link ablehnen konnte

RFC 2131, die DHCP-Spezifikation von 1997, behielt eine lokale Schlussprüfung. Server sollen wiederverwendete Adressen prüfen; Clients sollen nach DHCPACK feststellen, ob jemand sie bereits nutzt.

Der Client kann mit eigener Hardwareadresse, Ziel-IP als Kandidat und Null als Sender-IP fragen. Er behauptet die IP noch nicht und verschmutzt fremde Caches nicht. Bei Konflikt muss er DHCPDECLINE senden und neu beginnen. Nach Erfolg kündigt er die Zuordnung an, damit alte Werte verschwinden.

Der Lease koordiniert Pool und Zeit. ARP beobachtet den Ausführungsort. Eine korrekte Verwaltungsentscheidung kann auf eine reale Doppelbelegung treffen.

Von einmaliger Auflösung zur dauernden Konfliktbeobachtung

RFC 3927 definierte 2005 Probes und Announcements für IPv4 Link-Local. Zufällige Wartezeiten, Sender-IP Null, Konfliktzähler und Ratenbegrenzung verhindern synchrones Beanspruchen und pathologische ARP-Stürme. Nach erfolgreichem Probe kündigt der Host seine Adresse an, um veraltete Caches zu korrigieren.

Die Beobachtung läuft weiter. Zwei getrennte LANs können dieselbe Link-Local-Adresse haben und später verbunden werden. Ein früher Test kann die neue Topologie nicht binden.

RFC 5227 generalisierte 2008 IPv4 Address Conflict Detection. Ein Probe fragt „Nutzt sie jemand?“ und erklärt „Ich möchte sie nutzen“. Ein Announcement erklärt aktuelle Nutzung.

Bei Konflikt kann der Host aufgeben oder einmal verteidigen. Ein weiterer Widerspruch innerhalb DEFEND_INTERVAL zwingt normale Hosts zum Rückzug, damit keine endlose Broadcast-Schlacht entsteht. Kritische Infrastruktur darf anders konfiguriert sein, muss Verteidigung aber begrenzen und sichtbar machen.

Das erkennt Kollisionen, authentifiziert jedoch kein Recht. Angreifer können Konflikte vortäuschen; fehlende Antwort beweist keine dauerhafte Freiheit. Die Beobachtung reicht für eine revidierbare Betriebsentscheidung, nicht für globale Identität.

Was das ARP-Nummernregister nicht beherrschte

RFC 5494 gab IANA 2009 Regeln für Hardwaretypen und Opcodes und reservierte experimentelle Werte. Die Koordination sorgt dafür, dass Implementierungen Bits gleich verstehen.

Sie entscheidet nicht, welcher Rechner auf einem VLAN eine IP verwenden darf. Ein Register der Protokollgrammatik ist keine Instanz zur Authentisierung jeder mit dieser Grammatik geäußerten Behauptung.

Ein lokales Gedächtnis mit Ausgang

ARP verlangte keine globale Gesamttabelle. Es fragte nur im benötigten lokalen Bereich, nur bei Bedarf, und speicherte nur beim handelnden Host. Diese Unvollständigkeit war effizient.

Sie bleibt sicher, wenn sie revidierbar ist. Ein Proxy kann Abhängigkeit verstecken, eine Fälschung die jüngste Aussage liefern, ein statischer Eintrag seinen Kontext überleben. Das Kabel ist Zeuge, nicht Autorität. Der Host entscheidet über Cache, Senden, erneutes Prüfen, Verteidigen und Rückzug.

Quellen und Beweisgrenzen

RFC 826 beschreibt Format und Lernreihenfolge, RFC 1027 delegierte Antworten, RFC 1122 Ablauf und Request-Grenzen. RFC 2131 trennt DHCP-Lease und Linkprüfung; RFC 3927 und RFC 5227 regeln Probe, Announcement und Konflikt; RFC 5494 koordiniert Nummern.

Die Dokumente belegen Entwurf und Anforderungen, keine universellen Einführungsdaten. Ein ARP-Mitschnitt belegt eine Aussage auf einem Link zu einem Zeitpunkt, nicht automatisch Identität, Eigentum, Absicht oder Weiterleitung hinter einem Proxy.