Zusammenfassung

  • Eine IPv6-Adresse mit begrenztem Geltungsbereich kann in mehreren Zonen denselben Wert haben. Der Host ergänzt einen getrennten lokalen Zonenindex, wählt damit seine Schnittstelle und sendet den Index nicht im Paket.
  • RFC 6874 versuchte 2013, die ZoneID in URI-Syntax einzubauen. RFC 9844 verwarf diesen Weg 2025 als für Browser unpraktikabel und verlangte stattdessen eine Benutzerschnittstelle, die den lokalen Wert erfasst, prüft und in einen Interface-Index übersetzt.

Ein Standardformat ohne globalen Schnittstellennamen

RFC 5952 reduzierte 2010 die Vielfalt von IPv6-Textformen. Regeln für Nullkompression, Buchstaben und Klammern bei Ports erleichtern Vergleich, Suche und Konfiguration.

Die Zone-Erweiterung aus RFC 4007 gehört nicht zu dieser Kanonisierung. RFC 9844 weist darauf ausdrücklich hin. Eine kanonische Adresse kann mit verschiedenen lokalen Suffixen erscheinen; derselbe Suffix kann auf zwei Hosts verschiedene Links bezeichnen.

Auch eine Default-Zone ist keine portable Auflösung. RFC 4007 empfiehlt lokale Vorgaben und verwendet gewöhnlich Null als Default. RFC 9844 dokumentiert jedoch, dass nicht jedes Betriebssystem eine brauchbare Vorgabe anbietet, und nennt Linux.

Wenn eine Anwendung ohne explizite Zone funktioniert, beweist sie nur die lokale Voreinstellung dieses Laufs. Sie beweist nicht, dass die Adresse die Ausgangswahl enthielt. Inventare sollten daher Adresse, eingegebenen Namen, aufgelösten Index, Host und Zeitpunkt getrennt bewahren.

Ein Protokolleintrag mit begrenzter Aussage

Die Zeichenfolge in einem Log kann genau belegen, was ein Programm auf einem bestimmten Rechner verlangte. Sie belegt nicht, dass ein zweiter Rechner dieselbe Operation daraus rekonstruieren kann. Der Unterschied folgt nicht aus einer zufälligen Namenskonvention, sondern aus der Architektur begrenzter IPv6-Geltungsbereiche.

RFC 4291 definiert Link-Local-Adressen für genau einen Link. Router dürfen Pakete mit Link-Local-Quell- oder Zieladresse nicht auf einen anderen Link weiterleiten. Auf zwei getrennten Links darf daher jeweils fe80::1 vorkommen, ohne dass beide Werte eine gemeinsame globale Identität beanspruchen.

RFC 4007 trennte im März 2005 scope und zone. Der Scope bezeichnet die Größe eines topologischen Bereichs; eine Zone ist eine konkrete Instanz eines Bereichs dieser Größe. „Link-local“ benennt den Umfang, nicht den einen Link, den eine Anwendung benutzen soll.

Ist ein Knoten mit mehreren Zonen desselben Scopes verbunden, reichen die 128 Adressbits nicht zur lokalen Auswahl. Er vergibt eigene Zonenindizes. Diese Werte sind strikt lokal und müssen selbst an den beiden Enden desselben Links nicht übereinstimmen.

Der Zusatz im Log ist damit eine gebundene Aussage: Auf diesem Host sollte diese lokale Zone verwendet werden. Ohne Host, Zeitpunkt und damalige Schnittstellenbelegung wird aus Präzision nur noch gleich aussehender Text.

Zwei Felder statt einer verlängerten Adresse

Die grundlegende Socket-Schnittstelle hatte die Grenze bereits gezogen. RFC 3493 definierte im Februar 2003 für sockaddr_in6 das Adressfeld sin6_addr und das getrennte 32-Bit-Feld sin6_scope_id.

Der Selector wird zusammen mit der Adresse an den lokalen Kernel übergeben. Er hängt keine Bits an die IPv6-Adresse an und erscheint nicht als Feld des IP-Pakets. Der Host verbraucht die Zusatzinformation bei seiner Ausgangsentscheidung.

RFC 3493 definiert außerdem die Abbildung von Schnittstellennamen auf lokale Nummern. if_nametoindex() fragt das ausführende System. Ein unbekannter Name führt zum Fehlschlag; es gibt weder ein Internetverzeichnis für eth0 noch eine Abfrage beim Zielsystem.

Für Menschen empfahl RFC 4007 die Form <address>%<zone_id>. Implementierungen sollen nichtnegative Dezimalzahlen unterstützen und dürfen lokale Zeichenketten wie Interface-Namen annehmen. Weil der Scope aus der Adresse folgt, muss der Suffix nur zwischen Zonen dieses Scopes unterscheiden.

Die Form hat ausdrücklich keine Bedeutung für globale Adressen und soll nicht für Loopback benutzt werden. Sie ist für die Verwendung innerhalb eines Knotens bestimmt und darf nur übertragen werden, wenn alle beteiligten Auswerter ihre Semantik vereinbart haben.

Diese Einschränkung hält die Zuständigkeit klein. Der lokale Rechner kennt seine Schnittstellen. Der Empfänger erhält keinen Namen, den er weder benötigt noch verlässlich deuten könnte.

Freie Namen brauchen strenge Eingänge

RFC 4007 legte weder einen einheitlichen Zeichenvorrat noch eine maximale Länge für Zonenkennungen fest. Nichtnumerische Bedeutungen blieben implementierungsabhängig. Die Flexibilität passt zu unterschiedlichen Betriebssystemen, verlangt aber Schutz an jeder Eingabestelle.

RFC 9844 empfiehlt eine angemessene Längenbegrenzung und das Zurückweisen gefährlicher Werte wie NUL. Das held Erratum 8553 zu RFC 4007 vermerkt die fehlenden Grenzen und verweist auf die neue Sicherheitsanleitung.

Der Text kann Formular, Shell, Konfigurationsdatei, URI-Parser, Logger und System-API durchlaufen. Unterschiedliche Dekodierung, Normalisierung oder Terminierung kann bewirken, dass die angezeigte Zone nicht dem Kernel-Index entspricht.

Ein Erfolg mit %eth0 ist deshalb nur ein begrenzter Beleg. Auf diesem Host wurde der Name zu diesem Zeitpunkt aufgelöst und die Operation nutzte diesen Pfad. Er authentifiziert den Gegenüber nicht, beweist keinen Besitz, schafft keine globale Erreichbarkeit und macht den Namen nicht transportabel.

Der lokale Parameter im URI

Mit URIs kollidierten zwei Reichweiten. RFC 3986 ordnete sie im Januar 2005 als Identifikatoren globaler Reichweite, auch wenn einzelne Handlungen vom Kontext des Benutzers abhängen können. % leitet Prozentkodierung ein; ein literales Prozentzeichen in Daten wird als %25 geschrieben.

RFC 6874 schlug 2013 für den Klammerteil eines HTTP-URI Formen wie [fe80::a%25en1] vor. %25 stand für den Trennoperator %, danach folgte die lokale ZoneID. Browser und andere URI-Werkzeuge sollten damit Link-Local-Geräte ansprechen können.

Schon der Text erklärte, dass die ZoneID nur am Ursprungsknoten Bedeutung habe und vor einer ausgehenden HTTP-Anfrage entfernt werden solle. Was in der Adresszeile wie URI-Identität aussah, musste vor dem Netztransport verschwinden.

Daraus entstanden Entscheidungen über Origin-Vergleich, Verlauf, Lesezeichen, Proxy-Weitergabe und den Zeitpunkt der Dekodierung. Wenn zwei Schichten %25 unterschiedlich oder mehrfach dekodierten, konnte sich nicht nur die Darstellung, sondern die ausgewählte lokale Schnittstelle ändern.

Ein anderes Trennzeichen hätte das Grundproblem nicht beseitigt. Ein flüchtiger Parameter des Ursprungshosts war in ein Format geraten, das lange gespeichert, geteilt und zwischen Systemen verglichen wird.

Eine Rücknahme mit klarerem Vertrag

Im August 2025 erklärte RFC 9844 RFC 6874 vollständig für obsolet. Browser-Implementierer hatten den URI-Ansatz als unpraktikabel bewertet. Zugleich nahm das Dokument dessen Änderung an RFC 3986 zurück; das verifizierte Erratum 8552 hält diesen Status fest.

Die neue Pflicht gilt der Oberfläche. Jede UI, die eine andere als eine globale Unicast-Adresse akzeptiert, muss die Eingabe oder Auswahl einer Zonenkennung ermöglichen. Die vollständige %-Form wird bevorzugt, doch getrennte Felder, Listen, andere Separatoren oder eigene Parameter sind zulässig.

Adresse und Kennung bleiben intern getrennt. Die Anwendung wandelt die Kennung in einen lokalen Interface-Index um und soll einen ungültigen Wert als Fehler melden. POSIX inet_pton() kann fe80::1%eth0 allein nicht verarbeiten. Dafür braucht das Programm getaddrinfo() oder eine Trennung mit inet_pton() und if_nametoindex().

RFC 9844 nimmt Browser-Fetch-Semantik ausdrücklich aus. Es schafft keine neue Link-Local-URL-Identität und löst keine HTTP-Origin-Frage. Es sorgt dafür, dass ein notwendiger lokaler Parameter eingegeben werden kann, ohne ihn übertragbar zu erklären.

Die Norm behielt also die Bedienbarkeit und verkleinerte den Anspruch. Genau diese Verkleinerung machte die Verantwortungsgrenze testbar.

Lokaler Kontext als Beweiskette

Eine belastbare Ausführung kann jeden Übergang festhalten: Benutzereingabe, syntaktische Prüfung, Namensauflösung, Interface-Zustand, Socket-Aufruf und Netzresultat. Kein Schritt beweist automatisch den nächsten. Ein akzeptierter String ist noch kein vorhandenes Interface; ein gesendetes Paket ist noch keine bestätigte Identität.

Der Zonenindex bleibt außerhalb des Pakets, weil er dort seine Beweiskraft verlieren würde. Er gehört zur Entscheidung des Senders. Das Netz erhält den interoperablen Teil; der lokale Namensraum bleibt beim Eigentümer seiner Bedeutung.

Die Adresse mit dem nicht übertragbaren Zusatz ist daher kein halbfertiges Format. Sie ist eine bewusste Trennung zwischen gemeinsamer Adressarchitektur und lokaler Ausführung. Wer den Zusatz weitergibt, überträgt Zeichen, aber nicht die Autorität, die ihnen Bedeutung gab.

Quellen