Zusammenfassung

  • RFC 1433 ergänzte einen Routeneintrag um eine ARP Helper Address, damit ein Next Hop aus einem anderen IP-Netz auf demselben Linkdienst aufgelöst werden konnte.
  • Der Helper musste lokal und ohne Directed-ARP-Rekursion erreichbar sein; Route, physische Schnittstelle und Filter gegen Flut und Schleife begrenzten jede Weiterleitung.
  • Eine Linkadresse garantierte keinen Pfad: nichttransitive oder asymmetrische Filter konnten einen Dritt-Next-Hop auflösbar, aber unbenutzbar machen.

Gemeinsame Infrastruktur, getrennte Auflösung

RFC 1433 beschrieb mehrere administrativ getrennte IP-Netze auf einem Link-Level-Netz, etwa einem SMDS-Dienst. Ein Router mit Adressen in zwei Netzen konnte erkennen, dass beide denselben unteren Dienst nutzten. Er konnte einen direkteren Next Hop ankündigen und den Umweg über sich selbst vermeiden.

Der Empfänger wusste danach die IP-Adresse und die Ausgangsschnittstelle. Ihm fehlte dennoch die Adresse für den Linkrahmen. Auflösungsverfahren waren je IP-Netz organisiert. Das fremde Netz konnte eine andere ARP Request Address oder ein administriertes Verfahren verwenden. Ein günstiger Routeneintrag war noch nicht ausführbar.

Directed ARP ließ das normale ARP-Format bestehen. Es fügte der Route den Router hinzu, an den die Auflösungsfrage gerichtet werden sollte. Damit blieben Auswahl auf IP-Ebene und Zustellung auf Linkebene als zwei Entscheidungen sichtbar.

Der Helper dokumentierte Abhängigkeit

Ein leerer ARP Helper bedeutete, dass der Empfänger den Next Hop lokal auflösen konnte. Ein gesetzter Wert bezeichnete den Router, der mitgeteilt hatte, die fremde Adresse liege auf demselben Link-Level-Netz. Der Informationslieferant wurde so zur ausführungsrelevanten Abhängigkeit.

Die Funktion prüfte zuerst den lokalen Auflösungsspeicher. Ohne Treffer und ohne Helper verwendete sie das örtliche Verfahren. Mit Helper löste sie zunächst dessen Adresse lokal auf, schickte ihm einen ARP Request für das fremde Ziel und wartete. Keine Antwort bedeutete keine Linkadresse und damit keinen weiterleitbaren IP-Datagrammrahmen.

Der Helper selbst durfte nicht wieder über Directed ARP gesucht werden. Diese Nichtrekursion verhinderte, dass ein Routeneintrag eine unendliche Folge von Helfern oder eine verborgene Schleife enthielt. Der erste Helper musste mit bereits vorhandenen lokalen Mitteln adressierbar sein.

Bei einer Distance-Vector-Ankündigung wurde gewöhnlich der Ankündiger zum Helper. Bei einem ICMP Redirect konnte der Absender diese Rolle übernehmen. Herkunft und Hilfspflicht blieben verbunden.

Weiterleitung oder stellvertretende Aussage

Ein Host verwarf einen ARP Request für eine andere Adresse. Ein Router durfte ihn nur dann richten, wenn das Ziel als zulässiger Next Hop oder direktes Ziel in der Routingtabelle stand und der zugehörige Eintrag dieselbe physische Schnittstelle nutzte, auf der die Anfrage eingetroffen war.

Nutzte das Zielnetz ARP, leitete der Router die Anfrage an dessen Request-Adresse weiter. Nutzte es ein anderes lokales Verfahren, konnte der Router die Zuordnung selbst ermitteln und mit „published ARP“ im Namen des Ziels antworten.

Beide Ergebnisse füllten möglicherweise denselben Cache, stammten aber aus verschiedenen Systemen. Im ersten Fall erreichte die Frage einen nachgelagerten Antwortenden; im zweiten übersetzte der Helper eine eigene lokale Zuordnung in ARP. Nur IP- und Linkadresse zu speichern, löschte diese Provenienz.

Die Antwort bewies weder Betreiberidentität noch Routenbefugnis, künftige Annahme oder Rückweg. Sie war eine zeit- und schnittstellengebundene Zuordnung.

Eine Frage brauchte ein Ausbreitungslimit

Weitergeleitete Entdeckungsanfragen konnten sich vervielfachen. RFC 1433 verlangte Filter, um ARP floods fehlerhafter Systeme einzugrenzen und ARP loops aus instabilem Routing oder falscher manueller Konfiguration zu beenden.

Vorgeschlagen wurden Ratenlimits für identische Quell-/Zielpaare, das Verbot einer Rücksendung an dieselbe Linkzieladresse des empfangenen Rahmens und das Nichtweiterleiten von Anfragen, die als Linkbroadcast eingetroffen waren. Die Regeln begrenzten Wiederholung, Reflexion und Reichweite.

Sie bestätigten nicht die Richtigkeit einer Antwort. Sie entschieden, wie viele gemeinsame Ressourcen eine offene Frage verbrauchen durfte. Da eine erste Anfrage verloren gehen konnte, mussten Zähler und Zeitfenster administriert werden. Zu streng bedeutete dauerndes Schweigen nach Verlust; zu locker hielt eine Schleife am Leben.

Ein belastbarer Datensatz enthält deshalb Eingangsschnittstelle, Linkzielklasse, Quell-/Zielpaar, Zähler, Fenster, Filterentscheidung und späteres Antwortresultat.

Ohne Auflösung verlor die Route ihre Grundlage

Konnte ein Host einen über Redirect gelernten fremden Next Hop nicht mehr auflösen, sollte er den abhängigen Routeneintrag löschen. Ein abgelaufener Helper durfte nicht eine scheinbar gültige Route zurücklassen, die nur Pakete verschluckte.

Auch Interoperabilität bestimmte Gültigkeit. Ein Directed-ARP-fähiger Router konnte einen fremden Next Hop an einen Peer ohne diese Fähigkeit senden. Der Peer verstand das Feld, aber nicht den Ausführungspfad. Der Ankündiger musste eventuell sich selbst als konventionellen, teureren Next Hop anbieten oder die administrierte Beziehung musste fremde Next Hops ausschließen.

Dieselbe Routeninformation war daher für zwei Empfänger nicht gleich vollständig. Fähigkeit und Helper-Zustand gehörten zum nutzbaren Vertrag.

Der dritte Hop entzog sich dem Beobachter

Bei gewöhnlicher dynamischer Information steht der Ankündiger für seine Mitteilung ein und zieht sie zurück, wenn sie ungültig wird. Ein Dritt-Next-Hop kann den Ankündiger aus dem Datenpfad nehmen. Dann sieht er eine Störung zwischen den beiden anderen Teilnehmern möglicherweise nicht.

Das SMDS-Beispiel ließ R1 mit R2 und R2 mit R3 kommunizieren, blockierte aber R1 mit R3. R2 konnte R3 tatsächlich erreichen und dennoch R1 einen direkten Next Hop empfehlen, den die Linkpolitik sperrte. Gemeinsame Nachbarschaft war nicht transitiv.

Filter konnten außerdem asymmetrisch sein: R3 sendete zu R1, während R1 nicht zurücksenden durfte. Ein beobachteter Rahmen in einer Richtung war kein Beleg für die andere. Ein gemeinsamer Linkdienst war keine vollständige Paarmatrix.

Der Test durfte die fragliche Kante nicht umgehen

RFC 1433 schlug einen ICMP Echo vor, der direkt an die Linkadresse des Next Hops ging. Ein normal an die IP-Adresse gerouteter Echo konnte einen anderen Pfad nehmen und erfolgreich sein, ohne die strittige lokale Verbindung zu prüfen.

Der Test musste die behauptete Abhängigkeit benutzen. Auch ein Erfolg galt nur für einen Zeitpunkt und Austausch. Er bestätigte nicht alle Verkehrsklassen, Symmetrie, Weiterleitung zum Endziel oder spätere Stabilität. Nachfolgende Änderungen blieben Aufgabe des dynamischen Routings.

Die Beweiskette umfasst Anzeige, Ankündiger, Helper, lokale Helper-Auflösung, gerichtete Anfrage, Antwortquelle, Zuordnung, Filterentscheidung, direkten Test, ersten Datenrahmen und Rückbeobachtung. Kein Schritt vertritt automatisch den nächsten.

Quellen und Grenzen

RFC 1433 definiert das Experiment; RFC 826 ARP; RFC 1209 den SMDS-Kontext; RFC 1267 und RFC 1247 BGP-3 und OSPF; RFC 1122 und RFC 792 Host- und ICMP-Grundlagen.

Die Quellen belegen weder heutige Nutzung noch universelles Produktverhalten, Angriffshäufigkeit oder aktuelle Empfehlung. RFC 1433 erklärt ausdrücklich, Sicherheitsfragen nicht zu behandeln. Dauerhaft ist die Trennung: Die Kontrollinformation kann einen Ausführer nennen, während der Link Auflösung, Zulassung und Fortbestand weiterhin selbst bestimmt.

Quellen