Zusammenfassung

  • RFC 1888 empfahl zunächst einen nativen IPv6-Adressplan und definierte erst danach vier optionale Kompatibilitätsmechanismen für NSAP.
  • Reversibilität beseitigte weder die Mehr-Link-Area, noch fehlende Präfixaggregation, noch den Wechsel von Host- zu Schnittstellenidentität.
  • RFC 4048 trennte später offenbar ungenutzte NSAP-in-IPv6-Verfahren von zwei Fehlern im Gegenweg; RFC 4548 reparierte nur den engen ICP-Namensraum.

Aggregation war die erste globale Rechnung

Der im August 1996 als Experimental veröffentlichte RFC 1888 war kein Internet Standard. Organisationen mit geplantem oder bereits eingesetztem OSI-NSAP-Schema sollten nach seiner ersten Empfehlung einen nativen IPv6-Plan entwerfen und die lokale Topologie möglichst bewusst neu abbilden.

Drei Unterschiede begründeten diesen Vorrang. Eine OSI/IS-IS-Area konnte mehrere physische Links umfassen; ein IPv6-Subnetz setzte einen Link voraus. Eine Area-Nummer als Subnetznummer zu kopieren bewahrte die Hierarchieziffer, aber nicht die Nachbarschaft am letzten Link.

Für Weitverkehrsskalierung mussten Adressen ein gemeinsames aggregierbares Präfix besitzen. Normale IPv6-Adressen und eingeschränkte NSAPA-Abbildungen erhielten es durch das Mapping nicht. So konnte die Funktion jeden Wert verlustfrei zurückrechnen und dennoch zusätzliche globale Routen erzeugen.

Auch die Identität wechselte ihre Ebene. Mehrere NSAPs konnten ein OSI-Endsystem über Schnittstellen hinweg bezeichnen, während IPv6-Adressen einzelnen Schnittstellen gehören. Die Abbildung sagte nicht, welche davon am Ziel erreichbar war. Die Migration von ES-IS, IS-IS und deren Infrastruktur lag ausdrücklich außerhalb des Dokuments. Mit den Bits kam kein Kontrollsystem.

Vier Verfahren verteilten die Restarbeit verschieden

Das erste setzte eine eingeschränkte ICD- oder DCC-NSAPA in eine mit 0x02 beginnende IPv6-Adresse von sechzehn Oktetten. Innerhalb der Teilmenge war es algorithmisch reversibel. RFC 1888 warnte trotzdem vor ineffizientem Routing und verlangte für eine Area mit mehreren physischen Subnetzen einen zusätzlichen Mechanismus.

Das zweite begann mit 0x03 und trug eine verkürzte NSAPA. Deren Hierarchie konnte bis zur Area führen, nicht bis zur vollständigen Identität. Eine komplette NSAPA destination option oder ein gekapseltes CLNP-Paket musste sie ergänzen. Der Empfänger entschied lokal über Weiterleitung, Entkapselung oder Verwerfen. Automatische Letzthop-Auflösung blieb offen; statische Zuordnung oder ein künftiges ES-IS-ähnliches Verfahren waren nur Möglichkeiten.

Auch die Fehlerspur war unvollständig. Übliche Autokonfiguration und Discovery funktionierten nicht unverändert, vollständige NSAPAs passten nicht einfach in IPv6 routing headers, und eine ICMP-Meldung an die verkürzte Quelladresse konnte verworfen werden. Das Übergangsverfahren konnte also nicht nur scheitern, sondern den Rückweg seines Fehlerbelegs verlieren.

Das dritte verwendete normales IPv6 und übergab dem Empfänger die vollständige Quell- oder Ziel-NSAPA als Option. Knoten ohne diese Funktion mussten sie nicht implementieren. Ein sichtbares Feld bewies deshalb nur die Sendung, nicht Parser, Aktivierung oder Handlung.

Das vierte bettete IPv6 in eine NSAPA von zwanzig Oktetten unter IANA AFI 35 und ICP null ein. Rekursive Einbettung war wegen möglicher Anomalien oder Schleifen im Zusammenhang mit RFC 1326 verboten. RFC 1629 liefert den ATM-NSAP-Kontext, RFC 3513 die spätere IPv6-Adressarchitektur; beide sind kein Betriebsnachweis für RFC 1888.

Nichtnutzung und fehlerhafte Spezifikation waren getrennte Befunde

RFC 4048 erklärte 2005, soweit dem IETF bekannt, seien die NSAP-in-IPv6-Abbildungen nie ernsthaft verwendet und von IPv6-Implementierungen nicht unterstützt worden. Das ist eine zugeschriebene, begrenzte institutionelle Einschätzung, keine Vollerhebung privater Versuche. Sie stützte Historic und die Rückgabe des früheren Präfixes an Reserved.

Die Gegenrichtung IPv6-in-NSAPA hatte dagegen neues Interesse gefunden, unter anderem für ATM. Abschnitt 6 enthielt zwei Fehler: ICP war ein 16-Bit-Feld von zwei Oktetten, nicht das einzelne dritte Oktett; und die vier dezimalen IDI-Ziffern wurden als zwei BCD-Oktette codiert, nicht als freie Binärzahl.

RFC 4548 ersetzte 2006 nur diesen Abschnitt. Unter AFI 35 bezeichnet der dezimale ICP 0 IPv6, ICP 1 IPv4; Werte 2 bis 9999 benötigen ein definiertes, veröffentlichtes Format und IETF consensus. Das heutige IANA-Register OSI NSAPA Numbers belegt diese Bedeutungen, nicht laufende Software oder Verkehr.

Die RFC-Editor-Seiten zu RFC 1888, RFC 4048 und RFC 4548 zeigen Status und Ersetzung. Die ICP-Korrektur belebte eingeschränkte oder verkürzte NSAP-in-IPv6-Adressen nicht wieder. Sie bewahrte einen schmalen legitimen Namensraum, während die umgebende Versuchsanordnung historisch blieb.

Der Nachweis folgt daher einer Kette: Entwurf, reversible Funktion, gültige Syntax, registrierte Kennung, Parser, Freischaltung, aggregierbare Route, Letzthop, Empfängerentscheidung, Anwendungsergebnis und unabhängige Nutzungsbeobachtung. Kein frühes Glied garantiert ein späteres.