Zusammenfassung

  • RFC 1476 führte eine eingehende Route durch Empfängerfilter, Metrik- und Optionsverarbeitung, Aggregation, aktive Auswahl für die Forwarding Database und einen gesonderten Sendefilter je Peer.
  • Klassen unbekannter Optionen konnten die Route unverändert weitergeben, die Option entfernen, die Route lokal halten oder vollständig verwerfen; keine Klasse belegte Vertrauen oder tatsächliche Paketweiterleitung.

Fünf Verben statt einer „gelernten Route“

RFC 1476 schlug RAP als experimentelles Distance-Vector-Protokoll vor. Es sollte von lokalen Netzen bis zu internationalen Carriern reichen. Anstelle einer starren Trennung zwischen Interior und Exterior Routing sollten konkrete administrative Policies die Grenzen ziehen.

Der Anspruch war weit, doch der Ablauf war präzise. Informationen kamen von RAP-Peers, Interfaces, statischer Konfiguration und anderen Protokollen. Ein Eingangsfilter reduzierte sie. Eine interne Datenbank hielt Kandidaten. Eine Auswahl lud aktive Routen in die IP Forwarding Database. Erst ein weiterer Filter erzeugte die Teilmenge, die an jeden Peer ging.

Der RFC-Editor-Eintrag belegt Dokument, Datum und Experimental-Status. Er belegt keine RAP-Installation, keinen FIB-Eintrag und keinen ausgelieferten Datenstrom.

Entscheidung eins: Das Angebot überstand den Eingang oder nicht

Receiver Filtering verwarf zu weit entfernte oder zu spezifische Routen. Ein Router konnte den Filter unter Ressourcendruck verschärfen. Wer universelle Erreichbarkeit bereitstellen sollte, musste dagegen alle endlichen Routen hereinlassen und anschließend aggregieren oder eine Default Route zu einem Router benutzen, der dies tat.

Der Text nennt eine irreversible Folge. Wird ein Filter später geöffnet, sind früher verworfene Angebote nicht automatisch vorhanden. Der Peer muss sie nicht erneut senden. Die neue Einstellung belegt nur die Bereitschaft zur Annahme, nicht den aktuellen Besitz der Route.

Ein erneutes Update, eine Kopie vor dem Filter oder ein Refresh wäre nötig. Eine Policy-Revision kann verlorene Eingabedaten nicht rekonstruieren.

Entscheidung zwei: Unwissen hatte festgelegte Konsequenzen

RAP erhöhte die Distanz, addierte Delay und Kosten und übernahm für MTU und Bandbreite das Minimum des Pfads. Bekannte Policy-Optionen konnten eine Route ausschließen. Für eine unbekannte Option galt ihre Klasse.

Klasse 0 bedeutete benutzen und weitergeben, wobei die Option unverändert mitgeführt werden musste. Klasse 1 erlaubte Benutzung und Weitergabe ohne die Option. Klasse 2 erlaubte lokale Benutzung, aber keine Weitergabe. Klasse 3 verwarf die ganze Route. Außer der Distanz im Header musste keine bestimmte Option überall verstanden werden.

Die Klasse war keine Authentisierung. Sie bestätigte weder Absender noch Inhalt und machte die angeordnete Reaktion nicht automatisch sicher. Typ und Klasse waren unabhängig. Ein Format konnte eine unbekannte Wertform für Logs lesbar machen, ohne ihre Bedeutung zu liefern. Klasse 1 bot laut RFC auch keine Vertraulichkeit: Der Typ konnte genullt und die restliche Beschreibung weitergesendet werden.

Die vorhandenen Artikel zu unbekannten IPv6-Optionen und zum BGP-Partial-Bit besitzen andere Mechanismen. Bei RAP ist entscheidend, dass die Behandlung unbekannter Attribute den späteren lokalen und externen Zustand verzweigte.

Drei Attribute, drei verschiedene Gefahren

Source Restriction legte fest, welche Quellen eine Route benutzen durften. Existierten Sicherheitsfilter in der Weiterleitung, mussten sie im Routenangebot sichtbar werden. Sonst konnte ein Paket eine scheinbar bessere Route wählen und am Ende lautlos vom Filter verworfen werden.

Die Darstellung konnte vertrauliche Sicherheitskonfiguration offenlegen. RFC 1476 verlangte eine vorsichtige Weitergabe in Richtung des berechtigten Netzes. Das ist eine Soll-Grenze, kein Nachweis dafür, dass eine reale Implementierung sie eingehalten hat.

AUP beschrieb eine kooperative Acceptable Use Policy, etwa den Ausschluss kommerzieller Nutzung. Der Text erklärte ausdrücklich, dass dies keine Sicherheitsbarriere wie ein Forwarding Filter war. Public warnte wiederum vor einem Broadcast-Medium im Pfad, das fremde Empfänger mitlesen konnten. Quellberechtigung, erlaubter Zweck und Medienexposition waren nicht austauschbar.

Entscheidung drei: Aggregation war ein Policy-Urteil

Spezifische Routen konnten in eine umfassendere Route über denselben Peer eingehen. RAP wollte aber nicht jeden möglichen Fall automatisch aggregieren. Policy-Attribute konnten die Zusammenfassung verhindern oder sogar dazu führen, dass die Route verschwand.

RFC 1338 dokumentiert den zeitgenössischen Druck zu Supernetting und Skalierung. RFC 1476 zeigt zusätzlich den Informationspreis: Eine kleinere Tabelle kann Unterschiede entfernen, die ein nachgelagerter Peer für seine Entscheidung benötigt. Aus einem Aggregate lässt sich sein vollständiger Satz von Beiträgen nicht ableiten.

Entscheidung vier: Erst Auswahl erzeugte aktiven Zustand

Nach der Aggregation wurden RAP-Kandidaten mit Routen aus anderen Protokollen kombiniert. Beliebige Attribute und lokale Regeln durften bestimmen, was in die IP Forwarding Database gelangte.

RFC 1058 bildete den RIP-Hintergrund für Distance Vector, RFC 1247 den OSPF-Hintergrund für Link State. Das Nebeneinander der Quellen bedeutete keine automatische Bevorzugung.

Eine Route in der RAP-Datenbank war kein Beleg für die FIB. Ein FIB-Eintrag belegte seinerseits noch nicht, dass ein bestimmtes Paket ihn traf, die Schnittstelle verließ oder am Ziel ankam.

Entscheidung fünf: Jeder Peer erhielt eine eigene Projektion

Der Sendefilter durfte nur aktive Routen anbieten, aber für jeden Peer eine andere Teilmenge bilden. Eine lokal verwendete Route konnte einem Nachbarn verborgen bleiben. Eine andere konnte ohne eine Option weitergehen. Klasse 2 hielt sie vollständig im lokalen System.

Datagrammfilter mussten im Angebot dargestellt werden, damit der Peer keinen Verkehr in ein Black Hole lenkte. Diese normative Pflicht ist nicht ihre Ausführungsquittung. Für den Nachweis wären der wirksame Filter, das genaue Angebot, die Auswahl des Peers und Paketbeobachtung nötig.

Eine lebende TCP-Verbindung konnte einen toten RAP-Prozess verdecken

RAP-Peers nutzten eine symmetrische TCP-Verbindung auf Port 38 und bestätigten einzelne Kommandos nicht. Poll und No Operation prüften Aktivität auf RAP-Ebene.

RFC 1476 riet davon ab, allein TCP Keepalive zu vertrauen. Es zeigte nur, dass der entfernte TCP-Stack Daten annahm, nicht dass der RAP-Prozess lebte. Bei Verbindungsbruch sollte jede Seite alle vom Peer angebotenen Routen löschen. Diese Regel brauchte in einer Implementierung eigene Ausführungslogs.

Auch die Loop-Korrektur war begrenzt. Distanzgrenzen und Trace sollten Schleifen schließlich brechen, aber nicht schnell; ein wiederkehrender Fehler konnte sie neu erzeugen. „Self-healing“ war keine Konvergenzmessung.

Historische Reichweite ohne erfundene Adoption

Das Begleitdokument RFC 1475 und sein Informationsdatensatz beschreiben TP/IX und die Forward Route ID. Der vorige Artikel besitzt bereits deren Next-Hop-private Bedeutung und die Add/Purge-Zeitgrenze. Hier geht es stattdessen um die fünf lokalen Entscheidungsflächen.

RFC 2026 hilft, Standardsprache von Betriebsbelegen zu trennen. Experimental wertet die Idee nicht ab und erhebt sie nicht zur verbreiteten Praxis.

Damit folgt die Analyse Heng Lus Texten über den Vorrang laufenden Codes, die minimale Anfangsspezifikation und lokalisierte spätere Entscheidung und Realitätsschichten. Das Angebot erreicht die Eingangstür. Es besitzt nicht die Autorität der späteren Filterung, Installation, Ausgabe oder Wirkung.

Quellen