11. Textual Representation (Textuelle Darstellung)

Wie bereits erwähnt, um eine nicht-globale IPv6-Adresse unzweideutig anzugeben, sollte auch die beabsichtigte Bereichszone angegeben werden. Als allgemeine Notation zur Angabe der Bereichszone SOLLTE eine Implementierung das folgende Format unterstützen:

<address>%<zone_id>

worin:

<address> eine wörtliche IPv6-Adresse ist,
<zone_id> eine Zeichenkette ist, die die Zone der Adresse identifiziert, und
% ein Trennzeichen ist, das zwischen <address> und <zone_id> unterscheidet.

Die folgenden Unterabschnitte beschreiben detaillierte Definitionen, konkrete Beispiele und zusätzliche Hinweise des Formats.

11.1 Non-Global Addresses (Nicht-globale Adressen)

Das Format gilt für alle Arten von Unicast- und Multicast-Adressen von nicht-globalem Bereich außer der nicht spezifizierten Adresse, die keinen Bereich hat. Das Format ist bedeutungslos und sollte nicht für globale Adressen verwendet werden. Die Loopback-Adresse gehört zum trivialen Link, das heißt, der Link, der der Loopback-Schnittstelle angebunden ist. Somit sollte das Format auch nicht für die Loopback-Adresse verwendet werden. Dieses Dokument spezifiziert nicht die Verwendung des Formats, wenn <address> die nicht spezifizierte Adresse ist, da die Adresse keinen Bereich hat. Dieses Dokument verbietet jedoch nicht, dass eine Implementierung das Format für diese speziellen Adressen für implementierungsabhängige Zwecke verwendet.

11.2 The `<zone_id>` Part

In der textuellen Darstellung SOLLTE der <zone_id>-Teil in der Lage sein, eine bestimmte Zone des Bereichs der Adresse zu identifizieren. Obwohl ein Zonenindex voraussichtlich genug Information enthält, um den Bereich zu bestimmen und unter allen Bereichen eindeutig zu sein, wie in Abschnitt 6 beschrieben, MUSS der <zone_id>-Teil dieses Formats nicht den Bereich enthalten. Dies liegt daran, dass der <address>-Teil den entsprechenden Bereich angeben SOLLTE. Dies bedeutet auch, dass der <zone_id>-Teil nicht unter allen Bereichen eindeutig sein muss.

Mit dieser gelockerten Eigenschaft kann eine Implementierung eine bequeme Darstellung als <zone_id> verwenden. Zum Beispiel, um Link-Index 2 darzustellen, kann die Implementierung einfach "2" als <zone_id> verwenden, was lesbarer wäre als andere Darstellungen, die den "Link"-Bereich enthalten.

Wenn eine Implementierung das Format interpretiert, sollte sie den "vollständigen" Zonenindex, der den Bereich enthält, aus dem <zone_id>-Teil und dem Bereich konstruieren, der durch den <address>-Teil angegeben ist. (Erinnern Sie sich, dass ein Zonenindex selbst den Bereich enthalten sollte, wie in Abschnitt 6 angegeben.)

Eine Implementierung SOLLTE mindestens numerische Indizes unterstützen, die nicht-negative Dezimal-Integer als <zone_id> sind. Der Standard-Zonenindex, der typischerweise 0 sein sollte (siehe Abschnitt 6), ist in den Integern enthalten. Wenn <zone_id> der Standard ist, können die Trennzeichen "%" und <zone_id> weggelassen werden. Ebenso, wenn eine textuelle Darstellung einer IPv6-Adresse ohne Zonenindex gegeben wird, sollte sie als <address>%<default ID> interpretiert werden, wobei <default ID> der Standard-Zonenindex des Bereichs ist, den <address> hat.

Eine Implementierung KANN andere Arten von nicht-null Zeichenketten als <zone_id> unterstützen. Die Zeichenketten dürfen sich jedoch nicht mit dem Trennzeichen widersprechen. Das genaue Format und die Semantik von zusätzlichen Zeichenketten sind implementierungsabhängig.

Ein möglicher Kandidat für diese Zeichenketten wären Interface-Namen, da Schnittstellen eindeutig alle Bereiche unterscheiden. Insbesondere können Interface-Namen als "Standard-Identifizierer" für Schnittstellen und Links verwendet werden, da standardmäßig eine Eins-zu-eins-Zuordnung zwischen Schnittstellen und jedem dieser Bereiche besteht, wie in Abschnitt 6 beschrieben.

Eine Implementierung könnte auch Interface-Namen als <zone_id> für Bereiche größer als Links verwenden, aber es könnte einige Verwirrung bei dieser Verwendung geben. Zum Beispiel, wenn mehr als eine Schnittstelle zum gleichen (Multicast-)Standort gehört, könnte ein Benutzer verwirrt sein, welche Schnittstelle verwendet werden sollte. Auch würde eine Zuordnungsfunktion von einer Adresse zu einem Namen das gleiche Problem haben, wenn es eine Adresse mit einem Interface-Namen als Zonenindex druckt. Dieses Dokument spezifiziert nicht, wie diese Fälle behandelt werden sollten, und lässt es implementierungsabhängig.

Es kann nicht angenommen werden, dass Indizes auf allen Knoten in einer Zone häufig sind (siehe Abschnitt 6). Daher MUSS das Format nur innerhalb eines Knotens verwendet werden und DARF NICHT auf dem Draht gesendet werden, es sei denn, jeder Knoten, der das Format interpretiert, erklärt sich auf die Semantik einig.

11.3 Examples (Beispiele)

Die folgenden Adressen

fe80::1234 (auf der 1. Link des Knotens)
ff02::5678 (auf der 5. Link des Knotens)
ff08::9abc (auf der 10. Organisation des Knotens)

würden wie folgt dargestellt:

fe80::1234%1
ff02::5678%5
ff08::9abc%10

(Hier nehmen wir eine natürliche Übersetzung von einem Zonenindex zum <zone_id>-Teil an, wobei die Nth Zone eines beliebigen Bereichs in "N" übersetzt wird.)

Wenn wir Interface-Namen als <zone_id> verwenden, könnten diese Adressen auch wie folgt dargestellt werden:

fe80::1234%ne0
ff02::5678%pvc1.3
ff08::9abc%interface10

wobei die Schnittstelle "ne0" zur 1. Link gehört, "pvc1.3" zur 5. Link gehört und "interface10" zur 10. Organisation gehört.

11.4 Usage Examples (Verwendungsbeispiele)

Anwendungen, die in End-Hosts wie telnet, ftp und ssh verwendet werden sollen, unterstützen möglicherweise nicht explizit den Gedanken des Adressbereichs, besonders von Link-lokalen Adressen. Ein Experte-Benutzer (z.B. ein Netzwerk-Administrator) muss jedoch manchmal sogar Link-lokale Adressen zu solchen Anwendungen geben.

Hier ist ein konkretes Beispiel. Stellen Sie sich einen Multi-Link-Router namens "R1" vor, der mindestens zwei Punkt-zu-Punkt-Schnittstellen (Links) hat. Jede der Schnittstellen ist mit einem anderen Router, "R2" bzw. "R3", verbunden. Nehmen Sie auch an, dass die Punkt-zu-Punkt-Schnittstellen nur Link-lokale Adressen haben.

Stellen Sie sich nun vor, dass das Routing-System auf R2 hängt und erneut aufgerufen werden muss. In dieser Situation könnten wir möglicherweise keine globale Adresse von R2 verwenden, da dies ein Routing-Problem ist und wir nicht erwarten können, genug Routen für globale Erreichbarkeit zu R2 zu haben.

Daher müssen wir uns zunächst bei R1 anmelden und dann versuchen, uns bei R2 anzumelden, indem wir Link-lokale Adressen verwenden. In diesem Fall müssen wir die Link-lokale Adresse von R2 geben, zum Beispiel an telnet. Hier nehmen wir an, dass die Adresse fe80::2 ist.

Beachten Sie, dass wir nicht einfach

% telnet fe80::2

eingeben können, da R1 mehr als einen Link hat und daher der telnet-Befehl nicht erkennen kann, welche Link verwendet werden sollte. Stattdessen sollten wir die Link-lokale Adresse mit dem Link-Index wie folgt eingeben:

% telnet fe80::2%3

wobei "3" nach dem Trennzeichen % dem Link-Index der Punkt-zu-Punkt-Link entspricht.

Eine Erweiterung zur empfohlenen Basis-API definiert, wie das Format für nicht-globale Adressen in Funktionen der Bibliothek behandelt werden sollte, die einen Knotennamen in eine Adresse übersetzen oder umgekehrt [11].

11.6 Omitting Zone Indices (Zonenindizes weglassen)

Das in diesem Dokument definierte Format beabsichtigt nicht, das ursprüngliche Format für nicht-globale Adressen zu ungültig zu machen, das heißt, das Format ohne den Zonenindex-Teil. Wie in Abschnitt 6 beschrieben, können in einigen häufigen Fällen mit dem Gedanken des Standard-Zonenindex keine Mehrdeutigkeit über Bereichszonen bestehen. In einer solchen Umgebung kann die Implementierung den "%<zone_id>"-Teil weglassen. Infolgedessen kann sie so handeln, als würde sie das erweiterte Format überhaupt nicht unterstützen.

11.7 Combinations of Delimiter Characters (Kombinationen von Trennzeichen)

Es gibt andere Arten von Trennzeichen, die für IPv6-Adressen definiert sind. In diesem Unterabschnitt beschreiben wir, wie sie mit dem Format für nicht-globale Adressen kombiniert werden sollten.

Die IPv6-Adressarchitektur [1] definiert auch die Syntax von IPv6-Präfixen. Wenn der Adressteil eines Präfixes nicht-global ist und seine Bereichszone disambiguiert werden sollte, sollte der Adressteil im Format sein. Zum Beispiel kann ein Link-lokales Präfix fe80::/64 auf der zweiten Link wie folgt dargestellt werden:

fe80::%2/64

Bei dieser Kombination ist es wichtig, den Zonenindex-Teil vor der Präfixlänge zu platzieren, wenn wir das Format durch eine Namen-zu-Adressen-Bibliotheksfunktion [11] analysieren möchten. Das heißt, wir können zuerst die Adresse mit dem Zonenindex von der Präfixlänge trennen und einfach die erste an die Bibliotheksfunktion übergeben.

Das bevorzugte Format für wörtliche IPv6-Adressen in URLs ist auch definiert [12]. Wenn ein Benutzer das bevorzugte Format für eine nicht-globale IPv6-Adresse, deren Zone explizit angegeben werden sollte, eingibt, könnte der Benutzer das Format für die nicht-globale Adresse kombiniert mit dem bevorzugten Format verwenden.

Jedoch wird die eingegeben URL oft auf dem Draht gesendet, und es würde Verwirrung verursachen, wenn eine Anwendung den <zone_id>-Teil nicht entfernen würde, bevor es gesendet wird. Beachten Sie, dass Anwendungen sich keine Sorgen machen müssen, welche Art von Adressen sie verwenden, viel weniger das <zone_id>-Teil einer Adresse analysieren oder entfernen müssen.

Auch das Format für nicht-globale Adressen könnte mit der URI-Syntax [13] konfligieren, da die Syntax das Trennzeichen (%) als Escape-Zeichen definiert. Dieser Konflikt würde erfordern, zum Beispiel, dass der <zone_id>-Teil für Zone 1 mit dem Trennzeichen als '%251' dargestellt wird. Es bedeutet auch, dass wir nicht einfach ein nicht-entkommenes Format von anderen Quellen als Eingabe zum URI-Parser kopieren könnten. Zusätzlich, wenn der URI-Parser das entkommene Format nicht vor der Übergabe an eine Namen-zu-Adressen-Bibliothek konvertiert, wird die Konvertierung fehlschlagen. Alle diese Probleme würden den Nutzen der textuellen Darstellung in diesem Abschnitt verringern.

Daher spezifiziert dieses Dokument nicht, wie das Format für nicht-globale Adressen mit dem bevorzugten Format für wörtliche IPv6-Adressen kombiniert werden sollte. In jedem Fall wird empfohlen, wann immer möglich, einen FQDN anstelle einer wörtlichen IPv6-Adresse in einer URL zu verwenden.