Zusammenfassung

  • RFC 1234 legte 1991 die IPX-über-UDP-Kapselung fest. Sie erlaubt, ein IP-Internet als ein IPX-Netz zu behandeln; bei einem bekannten Host bilden die letzten vier Oktette der IPX-Hostnummer dessen IP-Adresse ab.
  • Ein Broadcast wurde nicht internetweit gesendet. Server und Router sollten manuell erzeugte IP-Peer-Listen führen und für jeden Peer ein separates Unicast-Paket senden. Erreichen solche Pakete die gesamte Server-Peer-Group nicht, können Ressourcen laut RFC für ein Endsystem sichtbar, aber nicht erreichbar sein.

Das eine Netz war eine kontrollierte Abstraktion

RFC 1234 beantwortete zunächst eine enge technische Frage: Wie kann IPX über ein Netz laufen, das selbst nur IP transportiert? UDP-Kapselung schafft den Übertragungsweg. Die Hostnummer-Konvention macht auch den bekannten Unicast-Fall verständlich: zwei führende Oktette bleiben Null, vier folgende tragen die IP-Adresse des Nodes.

Diese Klarheit sagt jedoch nichts darüber, ob das IP-Internet ein physisches LAN, eine einheitliche Administration, ein gemeinsamer Sicherheitsraum oder ein automatisch vollständiger Discovery-Raum ist. Das RFC erlaubt eine Sicht für die Implementierung. Es überlässt nicht der bloßen Bezeichnung „ein Netz“, wer eine Anfrage hören muss und ob diese Anfrage dort angekommen ist.

IPX benötigte Broadcast-Funktionen, damit NetWare-Server und IPX-Router in einem Netz einander finden können. Einen bekannten Zielhost anzusprechen und eine Frage an alle relevanten Teilnehmer zu verteilen, sind unterschiedliche Vorgänge. Der zweite verlangt eine definierte Empfängermenge und die tatsächliche Zustellung an jedes Mitglied.

Die Broadcast-Domäne wurde als Liste betrieben

Internetweiter IP-Broadcast war nach RFC 1234 weder angemessen noch verfügbar. Darum soll jeder Server und Router eine von Hand konstruierte Liste von IP-Peers unterhalten. Fordert IPX einen Broadcast an, simuliert die Kapselung ihn, indem sie für jeden Eintrag ein eigenes Unicast-Paket sendet.

Damit liegt die Reichweite nicht stillschweigend im gemeinsamen Medium. Sie liegt in der Liste, in ihrer Pflege und in der Lieferung jeder Kopie. Das RFC sagt ausdrücklich, dass mehrere Peer-Gruppen dasselbe IP-Internet teilen können, ohne voneinander zu wissen, weil die Listen manuell entstehen. Innerhalb einer Gruppe soll jede Liste alle Peers dieser Gruppe enthalten.

Ein IP-Pfad zwischen zwei Standorten beweist deshalb nicht, dass beide an derselben Discovery teilnehmen. Auch die Möglichkeit, sie als Teil eines logischen IPX-Netzes zu behandeln, beweist nicht die vollständige Reichweite einer Anfrage. Gemeinsamer Unterbau und vollständige Fragenverteilung sind getrennte Tatsachen.

Auch der Client musste die richtige Menge ansprechen

Die Last liegt nicht nur bei Servern und Routern. Ein Client in einem IPX-Netz muss Broadcasts senden, um den Router für ein gewünschtes Ziel zu entdecken. Seine Implementierung erhält eine konfigurierte Liste der IP-Adressen aller Server und Router der Peer-Group und sendet an jede Adresse eine Paketkopie.

Der Erfolg hängt damit auf beiden Seiten von Vollständigkeit ab: von den Listen der Server und Router und davon, dass der Client seine Suche an alle einschlägigen Server-Peer-Groups richtet. Ein Tunnel, der bekannten Unicast fehlerfrei weiterleitet, ergänzt keinen ausgelassenen Peer, berichtigt keine veraltete Adresse und stellt keine Kopie wieder her, die einen Teil der Gruppe dauerhaft verfehlt.

Die Formulierung des RFC ist bewusst bedingt. Wenn diese Pakete nicht dazu neigen, die gesamte Server-Peer-Group zu erreichen, können IPX-Ressourcen für ein Endsystem sichtbar und doch für dieses nicht erreichbar sein. Daraus wird kein konkreter Störfall, kein schuldiger Betreiber und keine reale Topologie. Belegt wird die Bedingung, unter der Sichtbarkeit und nutzbarer Weg auseinanderfallen können.

Bekannte Adressen entschieden nicht über Gruppenmitgliedschaft

Der Entwurf ist asymmetrisch. Der Ort eines bekannten Hosts lässt sich aus der IPX-Hostnummer ableiten. Ein Broadcast fragt hingegen, wer die Frage empfangen muss. Die Antwort steht nicht im Datagramm, sondern in einer veränderbaren Liste und in der Verantwortung für deren Pflege. RFC 1234 macht die IP-Topologie nicht zur automatischen Antwort auf diese Mitgliedschaftsfrage.

Multicast erscheint im Text als mögliche spätere Option; damals seien Multicast-Einrichtungen jedoch nicht weit verbreitet gewesen, es habe keine well-known Adresse und keine entsprechenden Implementierungen gegeben. Das ist mehr als historische Kulisse: Wer eine Liste durch Multicast, ein Register oder ein anderes Gruppenverfahren ersetzt, muss Mitgliedschaft, Zustelllücken und die Grenze zwischen Gruppen weiter sichtbar machen.

Das RFC nennt zudem harte Transportbedingungen. Der Standard-IPX-MTU beträgt 576 Bytes, das gekapselte IP-Gesamtpaket 604 Bytes. Die UDP-Prüfsumme ist optional, aber stark empfohlen, weil IPX gewöhnlich keine eigene Prüfsumme verwendet. Keine dieser Voraussetzungen macht eine Peer-Liste vollständig.

Quellen und Beweisgrenzen

Die geschlossene Quelle dieses Artikels ist RFC 1234, Tunneling IPX Traffic through IP Networks. Sie belegt Datum, UDP-Kapselung, Hostnummer-Konvention, Peer-Listen, Client-Discovery, die bedingte sichtbare-aber-nicht-erreichbare Folge, MTU, Prüfsumme und Sicherheitsbetrachtungen. Sie belegt keinen bestimmten Einsatz, keinen realen Ausfall, keine Organisationstopologie, keine heutige Nutzung und keinen aktuellen Status von UDP-Port 213.