Zusammenfassung

  • RFC 3147 ergänzte die fehlende Richtung: IPv4 oder IPv6 in GRE und das GRE-Paket als Nutzdaten eines CLNP-PDUs, um neue IP-Geräte hinter einem bestehenden CLNS-Netz zu erreichen.
  • Der vorgeschlagene N-SEL 47 wählte GRE am CLNS-Endpunkt; der GRE Protocol Type bezeichnete das innere Protokoll. Keiner der Werte bewies eine ausgeführte Managementhandlung.
  • Koexistenz machte das alte Netz zu einer Abhängigkeit des neuen. Abschaltung verlangte deshalb Nachweise über Ersatzweg, Paketgrößen, Schutz, Anwendungsergebnis, Gerätezustand und Rückkehr.

Das Ziel war modern, der Weg noch nicht

Die Managementnetze von SONET und SDH waren 2001 gewachsene Infrastruktur. Bellcore GR-253-CORE und ITU-T G.784 hatten CLNS für diese Aufgabe verlangt. Als Hersteller neue Elemente per IP verwalteten, änderte sich damit der Endpunkt, nicht automatisch das Netz zwischen Leitstelle und Gerät.

Es entstanden zwei spiegelbildliche Inseln. Ein altes CLNS-Element hinter einem neuen IP-Netz ließ sich erreichen, indem CLNP per GRE über IP transportiert wurde. Ein neues IP-Element hinter dem alten CLNS-Netz benötigte den umgekehrten Weg. Die erste Kapselung konnte die zweite nicht ersetzen.

RFC 3147 legte das IPv4- oder IPv6-Paket in GRE und das vollständige GRE-Paket in den Datenbereich eines CLNP Data Type PDU. CLNS leitete dieses PDU durch das Bestandsnetz. Der Tunnelausgang entfernte CLNP und GRE und gab das innere Paket an die IP-Seite weiter.

Der CLNS-Kern wurde dadurch nicht zu IP. Auch musste das verwaltete Element den Tunnel nicht kennen. Es entstand ein begrenzter Pfad zwischen Endpunkten, keine allgemeine Umwandlung. Diese Grenze trennte Kontinuität von Abschluss.

Drei Hüllen belegten drei Handlungen

Der innere IP-Header beschrieb das Managementgespräch. GRE nannte das eingeschlossene Netzprotokoll. CLNP trug Adressen und Weiterleitungslogik des tatsächlich durchquerten Bereichs. Jede Ebene konnte funktionieren, während eine spätere scheiterte.

Ein angekommenes CLNP-PDU belegte die Lieferung an den Tunnelausgang. Ein gültiger GRE-Header erlaubte die Interpretation. Ein ausgegebenes IPv6-Paket belegte die Entkapselung. Ob die Anwendung den Auftrag annahm, das richtige Gerät ihn ausführte und der Zustand sich änderte, blieb offen.

Auch die Identitäten waren verschieden. NSAP bezeichnete einen CLNS-Endpunkt, die IP-Adresse ein IP-Ziel, die betriebliche Geräteidentität möglicherweise Inventar, Zertifikat oder Standort. Ein einziges Adressfeld würde die Herkunft beim nächsten Wechsel überschreiben.

Eine belastbare Kette bewahrt Absicht, inneres Paket, GRE-Hülle, CLNP-Träger, Weiterleitung, Entkapselung, Anwendungsantwort und unabhängigen Gerätezustand. Kein Glied darf für die folgenden unterschreiben.

Die 47 öffnete nur den GRE-Eingang

CLNS unterschied Benutzer des Network Service mit dem letzten NSAP-Oktett, dem N-selector oder N-SEL. Beide Endpunkte brauchten eine gemeinsame Zahl für GRE-Daten. RFC 3147 schlug dezimal 47 vor, dieselbe Zahl, die GRE im IP-Protokollnummernraum trug.

Die Wiederverwendung war praktisch, aber keine Verschmelzung. N-SEL 47 wählte am CLNS-Endpunkt GRE. Erst der GRE Protocol Type sagte IPv4, IPv6 oder ein anderes inneres Protokoll. Wer jeden N-SEL 47 als IPv4 protokollierte, entfernte die nächste entscheidende Information.

„Vorgeschlagen“ blieb eine Begrenzung. Gemeinsame Werte ermöglichten herstellerübergreifende Arbeit. Die Veröffentlichung bewies weder universelle Implementierung noch gleiche Optionen oder einen erfolgreichen Einsatz bei einem benannten Betreiber.

Ein Audit benötigt Quell- und Ziel-NSAP, N-SEL, GRE-Version und Flags, Protocol Type, innere Adressen, Fingerabdruck und Zeit. „Tunnel aktiv“ ist kein ausreichender Beleg.

Der kleine Test konnte das große Loch verdecken

Kapselung vergrößerte Pakete. Ein innerer CLNS-Link konnte ein kleineres PDU-Limit haben, das die IP-Quelle nicht kannte. RFC 3147 empfahl das CLNP-Flag Segmentation Permitted. Ohne Erlaubnis durfte ein zu großes PDU verworfen werden, ohne der inneren Quelle eine brauchbare Erklärung zu liefern.

Eine kurze Abfrage oder ein Ping gelang, während eine größere Konfiguration verschwand. Der erste Test erklärte das Gerät für erreichbar; der zweite Fehler wurde der Anwendung zugeschrieben. Tatsächlich galt die Erreichbarkeit nur bis zu einer Größe.

Am Tunneleingang kam IPv4 Path MTU Discovery hinzu. Bei gelöschtem DF konnte vor der Kapselung fragmentiert werden. Bei gesetztem DF musste das Paket verworfen und ICMP fragmentation-needed gesendet werden. Auch diese Meldung benötigte einen Rückweg.

Ausgangslänge, DF, Overhead, Segmentierungserlaubnis, begrenzender Link, Fragmente, ICMP und Messpunkt gehören zusammen. Ohne sie sieht ein größenabhängiges schwarzes Loch wie ein zufälliger Gerätefehler aus.

Kapselung war kein Sicherheitsdienst

RFC 3147 stellte klar, dass CLNS und GRE hierfür keine Sicherheit lieferten. War Schutz nötig, musste eine andere Methode die Nutzdaten vor GRE über CLNS sichern. Der Tunnel authentisierte weder Gerät noch Bediener, verschlüsselte keinen Befehl und erteilte keine Berechtigung.

Ein Paket konnte auf allen Netzebenen korrekt und dennoch unerlaubt sein. Der Ausgang konnte identische Bytes liefern, die Anwendung sie aber ablehnen. Ebenso bewies eine Antwort ohne separate Identitätssicherung nicht das richtige Gerät.

Spätere GRE-Erweiterungen und heutige Schutzverfahren können einen Einsatz ergänzen. Sie dürfen nicht rückwirkend dem Text vom Juli 2001 zugeschrieben werden.

Der Übergang gab dem Altbestand neue Hebelwirkung

Sobald neue IP-Geräte GRE über CLNS benötigten, war CLNS nicht nur abzuschreibender Altbestand. Es wurde Teil des Betriebswegs der neuen Geräte. Eine zu frühe Abschaltung isolierte womöglich zuerst die Symbole der Modernisierung.

Das bedeutete keine ewige Laufzeit. Es bedeutete einen überprüfbaren Ausstieg: alternativer Pfad für jedes abhängige Gerät, Tests mehrerer Größen, mitwandernder Schutz, geübter Rückfall und bestätigter Gerätezustand nach dem Schnitt. Tunnelzähler reichten nicht.

Der CLNS-Betreiber kontrollierte Routen und NSAP-Plan, der IP-Betreiber die neue Erreichbarkeit, der Hersteller die Anwendung, der Betriebsverantwortliche den Schnitt. IETF konnte die Naht normieren, ohne diese Befugnisse zusammenzulegen.

Historisch kreuzten sich die Abhängigkeiten. CLNP über IP hielt alte Geräte hinter dem neuen Netz erreichbar; IP über CLNS erreichte neue Geräte hinter dem alten. Die minimale Spezifikation regelte den Übergang und ließ die Stilllegung lokal.

Laufender Code blieb Berufungsinstanz. Wenn die Hüllen ankamen und der Zustand unverändert blieb, war das Management gescheitert. Wenn nur kleine Pakete funktionierten, war der Pfad nicht allgemein nutzbar. Wenn CLNS der einzige Rückweg blieb, war der Ersatz unvollständig. Der Tunnel erhielt Zeit, nicht das Abschlusszertifikat.

Quellen