Zusammenfassung

  • RFC 3493 ließ einen AF_INET6-Socket mit IPv4-Gegenstellen über IPv4-gemappte IPv6-Adressen kommunizieren. IPV6_V6ONLY begrenzte ihn auf IPv6, war laut RFC jedoch standardmäßig ausgeschaltet.
  • Deshalb bewiesen Socketfamilie, Prozessname und erfolgreicher Wildcard-bind weder die tatsächliche Gegenstellenfamilie noch einen getrennten IPv4-Port. Effektiver Optionswert, Bind-Ergebnis und angenommener Verkehr waren eigene Belege.

Eine Migration zeigt die verborgene Abhängigkeit. Zwei Prozesse sollen dieselbe Portnummer verwenden: einer für IPv6, einer für IPv4. Die Konfiguration bleibt unverändert, doch der zuerst startende AF_INET6-Listener kann je nach wirksamer Semantik beide Familien erfassen. Der zweite Prozess findet dann keinen freien Port mehr.

RFC 3493 trug IPv4 über IPv4-gemappte IPv6-Adressen in die IPv6-API. Die 32 Bit der IPv4-Adresse stehen unter dem festen Präfix ::ffff: in einer 128-Bit-Struktur. Eine Anwendung kann damit über AF_INET6 einen IPv4-Knoten erreichen. Beim Empfang kann der Kernel die Gegenstelle als sockaddr_in6 zurückgeben; IN6_IS_ADDR_V4MAPPED() erkennt diese Form.

Diese Struktur ist eine Darstellung an der Grenze zwischen Anwendung und Kernel. Sie belegt weder natives IPv6 am entfernten Host noch einen reinen IPv6-Pfad. Ebenso sagt sie nichts über Autorisierung oder Serviceergebnis. Die Familie der Struktur und die Familie der beobachteten Netzkommunikation sind nicht derselbe Nachweis.

Abschnitt 5.3 führte IPV6_V6ONLY ein. Ist die boolesche Option aktiv, darf ein AF_INET6-Socket nur IPv6-Kommunikation führen. RFC 3493 setzte sie standardmäßig auf aus. In diesem historischen Vertrag konnte ein IPv6-Wildcard-Listener natives IPv6 und gemappt dargestelltes IPv4 annehmen.

Das Beispiel im RFC betrifft unmittelbar Portbesitz. Mit aktivierter Option können zwei Versionen desselben Servers auf derselben Portnummer laufen, eine über IPv6 und eine über IPv4. Die Option ist daher kein dekoratives Attribut. Sie entscheidet mit, ob ein bind den Namensraum einer oder zweier Familien belegt und ob ein zweiter Listener überhaupt starten kann.

Eine Prozessliste reicht nicht. Sie kann zwei Prozesse zeigen, obwohl einer seinen bind verloren hat. Eine Socketliste reicht ebenfalls nicht, wenn AF_INET6 automatisch als IPv6-only gelesen wird. Erforderlich sind Familie, zurückgelesener Wert von IPV6_V6ONLY, Bind-Adresse, Namespace, Port, Rückgabecode und die tatsächlich angenommenen nativen oder gemappten Gegenstellen.

Eine Einschränkung verhindert vorschnelle Schlüsse. Laut RFC wirkt die Option nicht auf gemappte Adressen, die durch SIIT als gültige IPv6-Kommunikation eintreffen. RFC 6052 und RFC 6145 beschreiben eingebettete Adressen und Paketübersetzung; das ist nicht dasselbe wie die lokale Dual-Stack-Darstellung. Aus ::ffff: allein folgt nicht, wo die Abbildung stattfand.

Auch Namensauflösung liefert nur Kandidaten. getaddrinfo() filtert nach Familie und Flags. RFC 6724 behandelt Auswahl, RFC 8305 lässt IPv6- und IPv4-Pfade gegeneinander antreten. Kandidat, Portbesitz, Verbindung, Autorisierung und abgeschlossener Dienst bleiben getrennte Stufen.

Der ausgeschaltete Default ist ein datierter Befund. RFC 3493 ist Informational, löste RFC 2553 ab und verweist für den formalen API-Standard auf eine andere Spezifikation. Heutige Systeme, Laufzeiten und Plattformen können abweichen. Gegenwart darf nicht aus dem Wert von 2003 geraten werden.

Die belastbare Methode lautet deshalb: deklarierte Familie, effektive Option, Bind-Grenze, Portbesitz, Gegenstellendarstellung, Anwendungspolitik und Ergebnis einzeln festhalten. Ohne diese Kette kann „IPv6-Listener“ einen IPv4-Eingang oder einen nie gebundenen IPv4-Prozess verdecken.

Quellen