Zusammenfassung

  • Die Kernfunktionen nahmen bereits einen undurchsichtigen Adresszeiger samt Länge entgegen. Ihre Signatur konnte bleiben, während PF_INET6, sockaddr_in6 und neue Namens- und Umwandlungsfunktionen nötig wurden.
  • Ein altes PF_INET-Programm sollte weiterhin IPv4-Gegenstellen erreichen. Ein neues PF_INET6-Programm konnte eine IPv4-Gegenstelle als IPv4-mapped IPv6-Adresse darstellen. Das sind zwei Zusagen, keine Messung erfolgreicher IPv6-Dienste.

Man sieht die Grenze am besten bei einem offenen Socket, den ein Prozess an den nächsten übergibt. Der Empfänger kennt getpeername(), rechnet aber womöglich mit der falschen Adressstruktur. Die gleiche Funktion kann dann einen falsch verstandenen Wert liefern. Der RFC 2133 behandelte 1997 diesen Übergang. Er erschien als informatives Dokument und wurde später durch RFC 2553 abgelöst. Seine Aussagen beschreiben eine historische Konstruktion, keine heutige Programmieranleitung.

Der Größenunterschied war zwingend: IPv4-Adressen umfassen 32 Bit, IPv6-Adressen 128. Die Socket-Kernfunktionen übergaben Adressen über Zeiger und Längenangaben. Deshalb mussten Namen und Parameterfolgen von bind(), connect() und sendto() nicht neu erfunden werden. In sockaddr_in passten die vollständige IPv6-Adresse, Port und Familie trotzdem nicht hinein. Der RFC führte AF_INET6, PF_INET6 und sockaddr_in6 ein und beschrieb erweiterte Namensauflösung sowie Textumwandlung. Selbst bei BSD 4.3 und 4.4 unterschied sich die Anordnung der Längen- und Familienfelder. Programme mit festen Puffern oder Annahmen über die Strukturgröße hatten Arbeit vor sich.

Die erste Kompatibilitätszusage galt vorhandener Software. Eine Implementierung sollte PF_INET und sockaddr_in weiter unterstützen, sodass alter Quellcode und bereits gebaute Programme wie zuvor mit IPv4-Knoten kommunizieren konnten. Daraus folgt keine IPv6-Fähigkeit des alten Binaries. Die zweite Zusage betraf neue PF_INET6-Programme: Sie konnten einen IPv4-Partner in sockaddr_in6 als ::FFFF:<IPv4-Adresse> ausdrücken. Diese Schreibweise verpackt eine IPv4-Adresse für die API. Sie ist kein Beleg dafür, dass der Partner oder die Pakete IPv6 nutzten.

Auch Wildcard- und Loopback-Adressen haben begrenzte Bedeutung. Mit der nicht spezifizierten IPv6-Adresse kann das System eine lokale Adresse wählen; Loopback bleibt auf dem eigenen Rechner. Beides sagt nichts über die Erreichbarkeit eines Dienstes aus einem entfernten Netz. Die Spezifikation liefert Regeln für Aufrufe, aber keine Messdaten aus einer Installation.

Für die Prozessübergabe sah RFC 2133 die historische Option IPV6_ADDRFORM vor. Sie sollte die Adresssicht eines offenen Sockets zwischen PF_INET und PF_INET6 umstellen. Eine Umstellung zurück auf IPv4 war nur erlaubt, wenn alle bereits gebundenen Nicht-Wildcard-Adressen IPv4-mapped waren. Der Zustand im Kernel setzte also eine tatsächliche Grenze; bloßes Umbenennen genügte nicht. Aus dem inzwischen obsoleten Vorschlag lässt sich keine einheitliche Unterstützung in aktuellen Systemen ableiten.

Ein lokaler Bezug erschien außerdem bei Schnittstellenindizes. if_nametoindex verband einen Namen mit einer vom Kernel vergebenen Nummer. Multicast-Optionen wählten eine Ausgangsschnittstelle oder lokale Gruppenmitgliedschaft. Diese Einstellungen zeigen weder Zustellung an andere Rechner noch Verarbeitung durch eine Anwendung. Selbst eine erfolgreiche Namensauflösung ist zunächst nur ein möglicher Eingabewert für eine Verbindung.

Als redaktioneller Maßstab hilft Lu Hengs Gedanke des laufenden Codes: Eine dokumentierte Möglichkeit und ein beobachtetes Ergebnis sind getrennt zu belegen. Die technische Grundlage hierfür bleibt der RFC; der Essay ist eine Perspektive, kein zusätzlicher Protokollbeleg.

Quellen: RFC 2133, RFC-Editor-Status und RFC 2553.