Zusammenfassung

  • RFC 1504 trennte die tunnelweite Identität aus Domain Identifier und ursprünglichem Netzbereich von der lokalen Nummer, unter der ein empfangender Router das entfernte Netz darstellte.
  • Kehrte diese lokale Nummer über einen redundanten Pfad ohne DI/UI-Provenienz zurück, konnte der Erzeuger seine eigene Abbildung für ein neues Netz halten, erneut abbilden und ein shadow network erzeugen.
  • Route, RI-Ack und MIB-Zeile belegten jeweils nur einen Ausschnitt. Identität und Wirkung erforderten Abbildungsepoche, Port, Verbindung, Sequenz, Snapshot, Ereignis und Payload-Beobachtung.

Drei Nummern für einen Gegenstand

RFC 1504 erschien im August 1993 als Informational RFC von Alan Oppenheimer, Apple Computer. Das Dokument sollte ein Apple-Protokoll festhalten, das über das Internet laufen konnte. Es legte keinen Internetstandard fest und berichtet keine Einsatzstatistik.

AURP verband AppleTalk-Phase-2-Internets über fremde Netze wie IP oder Punkt-zu-Punkt-Verbindungen. Es transportierte Daten, verteilte Routinginformationen zwischen Exterior Routers und präsentierte entfernte Netze gegenüber lokalen Knoten.

Diese drei Flächen konnten verschiedene Nummern zeigen. Auf dem Tunnel besaß das exportierte Netz eine UI. Im lokalen AppleTalk-Internet erschien es unter einer Nummer aus dem Remapping-Bereich. In Managementdaten konnte die ursprüngliche, nicht abgebildete Nummer stehen.

Keiner dieser Werte war erfunden. Gefährlich wurde erst ihre Zusammenlegung ohne Herkunft.

Unabhängige Verwaltung erzeugte legitime Kollisionen

Zwei Organisationen konnten denselben AppleTalk-Netzbereich verwenden, solange ihre Internets getrennt blieben. Nach dem Zusammenschluss über einen Tunnel war die Zahl nicht mehr eindeutig.

AURP bewahrte lokale Nummerierung durch eine kleine gemeinsame Identität. Ein remappender Router bildete die UI aus seinem auf dem Tunnel eindeutigen DI und dem ursprünglichen Netzbereich. Der empfangende Router wies dieser UI eine freie Nummer aus seinem lokalen Remapping-Vorrat zu.

Alte Knoten mussten keine globale Namensarchitektur lernen. Sie sendeten an eine normale AppleTalk-Nummer; der Grenzrouter übersetzte zwischen lokaler Präsentation und Tunnelidentität.

Die lokale Zahl enthielt aber weder DI noch Ursprung. Derselbe UI konnte an zwei Orten unterschiedliche Aliases erhalten. Dasselbe Alias konnte nach Wiederverwendung zu verschiedenen Zeiten unterschiedliche UIs bezeichnen. Zahlenvergleich allein bewies weder Gleichheit noch Verschiedenheit.

Die Abbildung brauchte eine Epoche

Static remapping band einen bekannten lokalen Bereich an einen bestimmten UI. Das vereinfachte Management, verbrauchte jedoch knappen Nummernraum. Dynamic remapping vergab Zahlen nach Bedarf und erhöhte die Reichweite; dafür änderte sich die Bedeutung einer Zahl über die Zeit.

RFC 1504 empfahl, eine Nummer erst wiederzuverwenden, wenn keine andere verfügbar war. Der Platz eines gerade ausgefallenen Netzes sollte nicht sofort an ein neu erschienenes Netz fallen. Eine aktuelle Tabelle kann leer sein, während verzögerte Pakete, Caches und andere Wege noch die alte Bedeutung tragen.

Der belastbare Datensatz lautet deshalb nicht „47 ist X“. Er lautet „Router R ordnete am Port P in Epoche E den UI <DI, Originalbereich> von T1 bis T2 dem lokalen Bereich 47 zu“. Die Epoche ist Teil der Identität, sobald Zahlen wiederverwendbar sind.

Der Remapper konnte nicht jedes Datenformat verstehen

RFC 1504 nannte die Felder, die ein Router umschreiben konnte: Netznummern im DDP-Header, NBP-Entity-Adressen und Routingdaten in AURP-Paketen. War eine DDP-Prüfsumme vorhanden, musste sie vor der Änderung geprüft und danach auf null gesetzt werden. Die alte Prüfsumme beschrieb nicht mehr das veränderte Paket.

Drittprotokolle konnten AppleTalk-Adressen an unbekannten Stellen in ihren Daten führen. Der Router konnte sie nicht sicher entdecken. Äußere Zustellung und Routing funktionierten, während eine innere Referenz falsch blieb. Der Anwendungsausfall widersprach der grünen Route nicht; er lag hinter ihrer Beweisgrenze.

Managementprotokolle konnten in Antworten ursprüngliche Nummern zurückgeben. Eine entfernte Station brauchte die AURP-Remapping-Datenbank des Routers, um daraus die lokale Darstellung zu gewinnen. RFC 1742 standardisierte später AppleTalk-MIB-Objekte für Ports, RTMP-Tabellen und Zähler. Sie erweiterten die Beobachtung, ohne die AURP-Zuordnung oder den Endeffekt automatisch zu belegen.

Eine Oberfläche, die Original, UI und Alias unter einer Spalte „Netz“ versteckt, löscht genau die Information, die den Schatten erklären könnte.

Das Alias kam durch die Hintertür zurück

Ein shadow network entstand, wenn neben dem Tunnel ein redundanter Weg dieselben AppleTalk-Internets verband. Ein entfernte UI wurde beim Eintritt lokal abgebildet. Das Alias verbreitete sich im lokalen Netz, nahm den zweiten Weg und erreichte den Router, der es erzeugt hatte.

Auf diesem Weg fehlte die Tunnelprovenienz aus DI und Originalbereich. Das zurückkehrende Alias sah wie ein echtes lokales Netz aus. Der Router konnte seine eigene Übersetzung nicht erkennen, bildete sie erneut ab und exportierte die neue Darstellung.

Nun verwiesen zwei Bereiche auf ein physisches Netz. Eine weitere Runde konnte einen dritten erzeugen. RFC 1504 nannte solche Einträge shadow networks. Die Kette lief, bis die scheinbare Entfernung das Hop-Limit überschritt.

Das Hop-Limit begrenzte Weiterleitung, stellte aber keine Identität wieder her. Ein wegen Distanz gelöschter Eintrag verriet nicht, welchem Original er als Schatten folgte.

Die Ursache war eine Kombination: lokale Übersetzung, ein Pfad außerhalb der angenommenen Grenze und eine Rückkehr ohne Provenienz. Eine gültige Präsentation wurde zum falschen Objektbeweis.

Das virtuelle Mehrpunktmedium konnte teilweise verbunden sein

AURP stellte einen Multipoint-Tunnel als einen virtuellen Datenlink dar. Jeder Exterior Router sendete dort split-horizoned Information: eigene lokale Netze ja, auf demselben Tunnel von anderen Exterior Routers gelernte Netze nein.

Das setzte direkte Kommunikation aller Teilnehmer voraus. In der Realität konnte ein Tunnel absichtlich oder versehentlich nur teilweise verbunden sein. B kommunizierte mit A und C, während A und C einander nicht erreichten. B konnte aus dem Protokollzustand gewöhnlich nicht erkennen, ob dies Policy oder Fehler war.

Zwei getrennte Tunnel konnten die wirkliche Nachbarschaft ehrlicher darstellen als ein gemeinsames Multipoint-Label. Die Abstraktion war nützlich, durfte aber nicht als Messung gelten.

Teilweises Remapping teilte auch die Schleifenerkennung

Remapping wurde pro Router konfiguriert. RFC 1504 warnte vor Mischbetrieb. Nummernkollisionen wurden wahrscheinlicher, und die Schleifenerkennung galt nicht symmetrisch.

Remappende Router führten die zugehörige Loop Detection aus. Nicht remappende Router taten dies nicht. Eine Schleife zwischen letzteren konnte unentdeckt bleiben und einem remappenden Router mehrere Schattenkopien liefern.

Redundante remappende Router mussten für dasselbe lokale Internet denselben DI und dieselben UI-zu-Alias-Abbildungen verwenden. Der Text nannte vollständige gemeinsame Konfiguration oder eine künftige Verteilung, stellte aber fest, dass AURP diese Funktion damals nicht unterstützte.

Der zweite Pfad war verfügbar, bevor ein Protokoll den zweiten konsistenten Identitätszustand lieferte.

Ähnlichkeit war Anlass für einen Test

Stimmten Bereichsgröße und Zonenliste einer empfangenen Route mit einem lokalen Netz überein, galt die Information als loop-indicative. RFC 1504 verlangte daraus kein sofortiges Urteil. Der Router sollte ein AppleTalk-Paket durch den Tunnel senden und beobachten, ob es über einen lokalen Port zurückkam.

Merkmalsgleichheit erzeugte eine Hypothese. Die Rückkehr derselben Probe belegte einen Pfad zu diesem Zeitpunkt. Sie bewies weder Verwaltungsabsicht noch Dauer noch Anwendungserfolg.

Ebenso eng war die Security-Aussage. Network und Device Hiding wurden als schwache Form von Sicherheit bezeichnet; allgemeine Sicherheitsfragen blieben offen. Unsichtbarkeit im Chooser war keine authentisierte Abwesenheit.

Ein RI-Ack bestätigte keine gemeinsame Gegenwart

AURP verband Initialaustausch und spätere Events. One-way connections besaßen IDs; Pakete Sequenznummern. Der Sender wartete auf RI-Ack und übertrug bei fehlender Bestätigung erneut.

Ein neuer Peer konnte sich verbinden, während Events noch ausstanden. Dann passte der initiale RI-Rsp-Snapshot scheinbar nicht zum folgenden RI-Upd. RFC 1504 definierte pragmatische Korrekturen: Distance Change eines unbekannten Netzes als Addition; Addition eines bekannten als Distance Change; bestimmte Down-Events unbekannter Netze ignorieren.

Diese Regeln ergaben einen brauchbaren lokalen Zustand, keinen atomaren Snapshot aller Peers. RI-Ack belegte ein Paket, nicht lokale RTMP-Weitergabe, identische Mappings oder Payload-Lieferung.

Bei Tabellenüberlauf fehlten Informationen dauerhaft, wenn keine neue Gesamtaufnahme angefordert wurde. Der Receiver sollte mit RI-Req die vollständige Routingtabelle beziehen. Nach einer Lücke konnte das jüngste Event die Vergangenheit nicht rekonstruieren.

Welche Belege den Schatten auflösen

Die Untersuchung muss <DI, Originalbereich>, lokales Mapping und Epoche, Connection ID und Sequenz, Snapshot/Event-Typ, Eingangsport und Pfad, Tabellenversion und Next Hop sowie Probe oder Payload zusammenführen.

Zwei verschiedene Zahlen können zu einem Original kollabieren. Eine Zahl kann zwei Epochen tragen. Eine gültige Route kann eine unübersetzte eingebettete Adresse transportieren. Erst der Join trennt reale Kollision, Doppelalias, Wiederverwendung, Schleifenschatten und Anwendungsfehler.

Was die Quellen nicht belegen

Die Quellen nennen keine AURP-Einsatzzahl, keine vollständige Produktkonformität, keinen realen Schattennetz-Vorfall und keine heutige Nutzung. RFC 1504 bewahrt Design und Warnung, keine laufende Umgebung.

RFC 1378 beschreibt AppleTalk-Verhandlung über PPP und AURP-Carriage, nicht Konvergenz. RFC 1742 definiert Managementobjekte, nicht die Vollständigkeit einer konkreten Mapping-Datenbank. Lu Hengs Texte liefern die offengelegte Leseregel: Spezifikation, Implementierung, lokale Präsentation, Verwaltungsentscheidung und beobachtete Wirkung bleiben getrennte Belege.

Das Alias war nicht unwirklich. Es konnte Pakete bewegen. Gerade deshalb durfte seine operative Gültigkeit nicht zur Behauptung werden, die Welt enthalte ein zweites Netz.

Quellen