Zusammenfassung

  • RFC 3338 setzte einen Übersetzer zwischen die Socket-API und die IPv4/IPv6-Stacks eines Hosts. Für einen Peer mit ausschließlich AAAA konnte er eine A-Antwort aus einem lokalen IPv4-Pool erzeugen und diesen Wert der wirklichen IPv6-Adresse zuordnen, ohne IP-Header zu übersetzen.
  • Der ausgegebene IPv4-Wert war Übersetzerzustand mit Geltungsbereich und Generation. Pool-Erschöpfung, Verdrängung und Wiederverwendung, Unterschiede der API-Semantik sowie die Lücke zwischen Host-AAAA und IPv6-Unterstützung eines konkreten Dienstes konnten die Illusion brechen.

Der Resolver lieferte eine Form, die das alte Programm verstand

Eine reine IPv4-Anwendung erwartete Ergebnisse im Stil von gethostbyname und IPv4-Socket-Strukturen. Eine Quelltextänderung konnte unmöglich sein, weil der Code nicht mehr verfügbar oder der Anbieter verschwunden war. RFC 3338 zielte auf genau diese Übergangslage: Der Host besaß bereits native IPv6-Konnektivität, einzelne Altanwendungen kannten jedoch nur die ältere Schnittstelle.

Der BIA-Namensauflöser fing den Aufruf ab und suchte sowohl A- als auch AAAA-Records. Gab es nur AAAA, wählte der Adressmapper einen Wert aus seinem internen IPv4-Pool, speicherte das IPv4–IPv6-Paar und baute eine A-Antwort für die Anwendung. Das Programm erhielt die vertraute Vier-Byte-Form und konnte unverändert fortfahren.

Übergab das Programm diesen Wert später einer IPv4-Socket-Funktion, fing der Funktionsmapper den Aufruf ab, schlug die IPv6-Adresse nach und rief die entsprechende IPv6-API auf. Die Pakete liefen über den nativen IPv6-Stack. Anders als Bump-in-the-Stack aus RFC 2767 musste BIA keine IPv4- und IPv6-Header in der Netzwerkschicht umschreiben.

Die scheinbare Adresse bezeichnete eine Tabellenzeile

Eine gewöhnliche Netzadresse lädt zu einer dauerhaften Auslegung ein: Dieser Wert identifiziert eine entfernte Schnittstelle oder einen Endpunkt. Der synthetische BIA-Wert sagte viel weniger. Nur in einer bestimmten Übersetzertabelle, in einem bestimmten Geltungsbereich und während einer bestimmten Generation verwies er auf eine IPv6-Adresse.

RFC 3338 nannte nicht vergebene Werte von 0.0.0.1 bis 0.0.0.255 als Beispiel für den internen Pool. Sie sollten den Host nicht verlassen. Eindeutigkeit war nur innerhalb der Übersetzergrenze nötig. Tabellen pro Knoten, Nutzer oder Prozess konnten denselben Bits unterschiedliche Bedeutungen geben.

Ein Protokoll, das nur den synthetischen Wert bewahrt, bleibt deshalb mehrdeutig. Eine brauchbare Spur benötigt Tabellenbereich, Eintragsgeneration, Erzeugungsanlass, IPv6-Referenz, DNS-Antwortsatz und Prozessidentität. Die „Adresse“ ähnelte eher einem Dateideskriptor als einem global bedeutsamen Ziel.

Wiederverwendung konnte das gestrige Handle zum heutigen anderen Peer machen

Der Pool war endlich. Wenn viele IPv4-Anwendungen viele IPv6-Hosts ansprachen, konnten die Werte ausgehen. Das RFC erörterte, den ältesten Eintrag freizugeben und seinen IPv4-Wert erneut zu vergeben. Das schuf Kapazität, änderte aber das Bezugsobjekt des Handles.

Eine alte Kopie in Anwendung, Cache, Log oder verspätetem Callback konnte nach der Wiederverwendung noch gültig aussehen. Der nächste Tabellenzugriff würde sie jedoch zu einem anderen IPv6-Host übersetzen. Dafür brauchte es keinen Konflikt im globalen Routing. Unterschiedliche Lebensdauerannahmen innerhalb eines Rechners genügten für Fehlzustellung und falsche Zuschreibung.

Belastbare Belege müssen Zuweisung, letzte Nutzung, Verdrängung, Wiederverwendung und Generation aufzeichnen. Ein Socket-Aufruf ist mit der Generation zu verbinden, die zu diesem Zeitpunkt aktiv war. Dieselben vier Bytes vor und nach der Wiederverwendung sind nicht dieselbe betriebliche Identität.

Funktionsübersetzung machte die APIs semantisch nicht gleich

Der Funktionsmapper ersetzte IPv4-Socket-Funktionen durch passende IPv6-Aufrufe. RFC 3338 warnte jedoch, dass beide APIs nicht vollständig kompatibel seien. IPv6 besaß Fähigkeiten ohne IPv4-Gegenstück. Raw Sockets, Zusatzdaten, ICMP-Werte, Wildcard-Regeln und in Anwendungsprotokolle eingebettete Adressen verlangten betriebssystemabhängige Behandlung.

Eine erfolgreiche Funktionsersetzung belegt nur, dass ein Aufruf ausgeführt wurde. Sie belegt nicht, dass jede Option, jeder Fehler und jede Nebenwirkung ihre ursprüngliche Bedeutung behielten. Eine Anwendung konnte von Adressfamilie, Strukturlänge, Rückgabeformat oder einem Fehler abhängen, den der Übersetzer nicht exakt nachbildete.

Die Belegkette hält daher ursprünglichen API-Namen und Argumente, erzeugten API-Namen und Argumente, Optionsumwandlung, Betriebssystemimplementierung, Rückgabestatus und Auslegung durch die Anwendung getrennt. „Keine Header-Übersetzung“ vereinfachte eine Schicht, beseitigte aber keine semantische Übersetzung.

Ein Host-AAAA bewies keine IPv6-Fähigkeit des gewählten Dienstes

Ein Dual-Stack-Server konnte AAAA veröffentlichen, weil einige Dienste IPv6 unterstützten, während das Programm am gewählten Port weiterhin nur IPv4 sprach. Ein BIA-Client konnte den AAAA-Pfad wählen, den Host erreichen und dennoch an der Dienstgrenze scheitern.

RFC 3338 erwog, jede zurückgegebene Adresse zu versuchen. Bei TCP konnte BIA möglicherweise einen fehlgeschlagenen connect beobachten und weitergehen. Bei UDP lieferte erfolgreiches Senden nicht zwingend eine unmittelbare, beobachtbare Antwort. Der Übersetzer konnte schwer oder gar nicht erkennen, welche Adresse funktionierte; die Anwendung musste die Iteration womöglich selbst übernehmen.

Die Trennung bleibt allgemein gültig. DNS belegt, dass ein Name Records besitzt. Netzwerkerreichbarkeit belegt, dass Pakete eine Adresse erreichen. Ein lauschender Port belegt einen Diensteinstieg. Anwendungserfolg belegt die verlangte Operation. Kein Beleg ersetzt den nächsten.

Die Kompatibilitätsschicht konnte zum Vorwand gegen die Portierung werden

Das RFC zog eine klare Produktgrenze. BIA war Experimental und für frühe IPv6-Anwender gedacht, die Altprogramme ohne verfügbaren Quelltext besaßen. Für den regulären Produktionseinsatz wurde es nicht empfohlen. War der Quelltext vorhanden, sollten Entwickler die Anwendung portieren; BIA durfte diese Arbeit nicht verzögern.

Diese Warnung erkannte ein institutionelles Risiko. Eine Brücke, die heute eine Lücke schließt, sammelt Tabellen, Ausnahmen, Beobachtungslogik und Betriebsabhängigkeiten. Der gegenwärtige Eigentümer hält das Altprogramm am Leben; spätere Betreiber erben verborgenes Resolver-Verhalten und zustandsgebundene Adressbedeutungen. Die Brücke zu entfernen kann schließlich schwieriger werden als die ursprüngliche Portierung.

In den Einführungsbeleg gehören deshalb Ausstiegskriterien: Welche Anwendungen erfüllen die Ausnahme? Wer besitzt die Portierungsaufgabe? Welche Aufrufe bleiben ungestützt? Welche Beobachtung erlaubt die Abschaltung? „Vorübergehend“ ohne solche Angaben wird leicht zur dauerhaften Architektur.

Späteres Verbindungsrennen löste ein benachbartes Problem anders

BIS aus RFC 2767 setzte die Übersetzung tiefer im Stack an und stützte sich auf SIIT aus RFC 2765. RFC 3338 verschob die Anpassung bewusst an die API-Grenze. RFC 2893 lieferte den damaligen Dual-Stack-Kontext, RFC 3493 dokumentierte später grundlegende IPv6-Socket-Erweiterungen und RFC 4038 ordnete Übergangsfragen für Anwendungen ein.

RFC 6555 und seine Aktualisierung RFC 8305 beschrieben später Happy-Eyeballs-Verfahren, die Verbindungsversuche über Adressfamilien anordnen oder gegeneinander laufen lassen. Sie mindern Verzögerung und Ausfall, ohne einen synthetischen IPv4-Wert zum privaten Alias eines IPv6-Peers zu machen. Diese spätere Logik in BIA hineinzulesen, würde den historischen Unterschied zwischen der Auswahl realer Kandidaten und dem Erzeugen eines veränderlichen lokalen Handles verwischen.

RFC 4291 definiert IPv6-Adressierung, gibt dem internen IPv4-Pool von BIA jedoch keine globale Bedeutung. Keines dieser Dokumente beweist außerdem, dass ein Anbieter oder Betreiber RFC 3338 tatsächlich einsetzte. Eine Spezifikation ist kein Bereitstellungsnachweis.

Jedes Kompatibilitäts-Handle braucht eine Generation

Der elegante Schritt von BIA bestand darin, die sichtbare Schnittstelle zu erhalten und die Implementierung darunter zu wechseln. Der Preis war verborgener Zustand. Was wie eine Adresse aussah, wurde zur Referenz in einer veränderlichen Tabelle; was wie ein gewöhnlicher Socket-Aufruf aussah, wurde zu einer abgefangenen Übersetzung.

Die dauerhafte Betriebsregel lautet, Darstellung und auslegende Autorität gemeinsam zu protokollieren. Eine synthetische A-Antwort braucht einen Mapping-Beleg. Ein übersetzter Aufruf muss Ursprungs- und Zielsemantik bewahren. Eine Verbindung muss tatsächliche IPv6-Adresse und Port sowie Transport- und Anwendungsergebnis tragen.

Ohne diese Verknüpfungen sieht ein Ermittler eine IPv4-förmige Zahl und schreibt ihr globale Bedeutung zu, die sie nie besaß. RFC 3338 war ein Übergangsmechanismus und zugleich eine Lektion über Handles: Die Bits sind nicht die Identität; die lebende, überprüfbare Zuordnung verleiht ihnen Bedeutung.

Quellen