Zum Hauptinhalt springen

5. Protocol Specification (Protokollspezifikation)

Die Autokonfiguration wird auf Schnittstellen, die Multicast unterstützen, auf einer Pro-Interface-Basis ausgeführt. Bei Multihomed-Rechnern wird die Autokonfiguration auf jeder Schnittstelle unabhängig ausgeführt. Die Autokonfiguration gilt hauptsächlich für Hosts, mit zwei Ausnahmen. Router sollen mit den unten beschriebenen Verfahren eine Link-Local-Adresse generieren. Darüber hinaus führen Router Duplicate Address Detection für alle Adressen durch, bevor sie diese einer Schnittstelle zuweisen.

5.1. Node Configuration Variables (Knoten-Konfigurationsvariablen)​

Ein Knoten muss (MUST) es ermöglichen, dass die folgenden autokonfigurationsbezogenen Variablen für jede Multicast unterstützende Schnittstelle durch die Systemverwaltung konfiguriert werden:

DupAddrDetectTransmits - Die Anzahl aufeinanderfolgender Neighbor Solicitation-Nachrichten, die beim Ausführen von Duplicate Address Detection für eine tentative Adresse gesendet werden. Ein Wert von Null zeigt an, dass Duplicate Address Detection nicht für tentative Adressen durchgeführt wird. Ein Wert von eins zeigt eine einzelne Übertragung ohne nachfolgende Neuübertragungen an.

Standardwert: 1, kann jedoch durch einen link-typ-spezifischen Wert in einem link-typ-spezifischen Dokument überschrieben werden, das Probleme im Zusammenhang mit der Übertragung von IP über einen bestimmten Link-Typ abdeckt (z. B. [RFC2464]).

Die Autokonfiguration setzt auch die Existenz der in [RFC4861] definierten Variablen RetransTimer voraus. Für Autokonfigurationszwecke gibt RetransTimer die Verzögerung zwischen aufeinanderfolgenden Neighbor Solicitation-Übertragungen an, die während der Duplicate Address Detection durchgeführt werden (wenn DupAddrDetectTransmits größer als eins ist), sowie die Zeit, die ein Knoten wartet, nachdem er die letzte Neighbor Solicitation gesendet hat, bevor er den Duplicate Address Detection-Prozess beendet.

Abgesehen von der Bildung einer Link-Local-Adresse und der Verwendung von Duplicate Address Detection liegt die Art und Weise, wie Router ihre Schnittstellen (automatisch) konfigurieren, außerhalb des Anwendungsbereichs dieses Dokuments.

Hosts pflegen eine Liste von Adressen mit ihren entsprechenden Lebenszeiten. Die Adressliste enthält sowohl autokonfigurierte als auch manuell konfigurierte Adressen.

Ein Knoten bildet eine Link-Local-Adresse, wann immer eine Schnittstelle aktiviert wird. Eine Schnittstelle kann nach einem der folgenden Ereignisse aktiviert werden:

  • Die Schnittstelle wird beim Systemstart initialisiert.
  • Die Schnittstelle wird nach einem temporären Schnittstellenausfall oder nachdem sie durch die Systemverwaltung temporär deaktiviert wurde, reinitialisiert.
  • Die Schnittstelle wird zum ersten Mal mit einem Link verbunden. Dies umfasst Fälle, in denen sich der verbundene Link dynamisch aufgrund einer Änderung des drahtlosen Netzwerkzugangspunkts ändert.
  • Die Schnittstelle wird nach administrativer Deaktivierung durch die Systemverwaltung aktiviert.

Die Link-Local-Adresse wird gebildet, indem das bekannte Link-Local-Präfix FE80::0 [RFC4291] (von geeigneter Länge) mit einem Interface Identifier wie folgt kombiniert wird:

  1. Die am weitesten links stehenden 'Präfixlänge'-Bits der Adresse sind die Bits des Link-Local-Präfixes.
  2. Die Bits in der Adresse rechts vom Link-Local-Präfix werden alle auf Null gesetzt.
  3. Wenn die Länge des Interface Identifiers N Bits beträgt, werden die am weitesten rechts stehenden N Bits der Adresse durch den Interface Identifier ersetzt.

Wenn die Summe aus Link-Local-Präfixlänge und N größer als 128 ist, schlägt die Autokonfiguration fehl, und eine manuelle Konfiguration ist erforderlich. Die Länge des Interface Identifiers ist in einem separaten link-typ-spezifischen Dokument definiert, das auch mit der Adressarchitektur [RFC4291] konsistent sein sollte (siehe Abschnitt 2). Diese Dokumente definieren die Längen sorgfältig, damit eine Link-Local-Adresse auf einem Link autokonfiguriert werden kann.

Eine Link-Local-Adresse hat eine unendliche bevorzugte und gültige Lebensdauer; sie läuft nie ab.

5.4. Duplicate Address Detection (Erkennung doppelter Adressen)​

Duplicate Address Detection muss (MUST) für alle Unicast-Adressen durchgeführt werden, bevor sie einer Schnittstelle zugewiesen werden, unabhängig davon, ob sie durch Stateless Autoconfiguration, DHCPv6 oder manuelle Konfiguration erhalten wurden, mit den folgenden Ausnahmen:

  • Schnittstellen, bei denen die Variable DupAddrDetectTransmits auf Null gesetzt ist, führen keine Duplicate Address Detection durch.

  • Eine Unicast-Adresse, von der bekannt ist, dass sie eindeutig ist (z. B. eine Adresse, die durch stateful manuelle Konfiguration oder DHCPv6 mit einem ausreichenden Mechanismus zur Verhinderung von Duplikaten erhalten wurde), kann (MAY) Duplicate Address Detection durchführen (ist aber nicht erforderlich (MUST NOT)).

  • Duplicate Address Detection darf (MUST NOT) für Anycast-Adressen durchgeführt werden (beachten Sie, dass eine Anycast-Adresse syntaktisch nicht von einer Unicast-Adresse unterschieden werden kann).

  • Jede einzelne Unicast-Adresse sollte (SHOULD) auf Eindeutigkeit getestet werden. Beachten Sie, dass bereitgestellte Implementierungen nur Duplicate Address Detection für Link-Local-Adressen durchführen und den Test für globale Adressen überspringen, die denselben Interface Identifier wie die Link-Local-Adresse verwenden. Obwohl dieses Dokument diese Implementierungen nicht ungültig macht, wird diese "Optimierung" nicht empfohlen (NOT RECOMMENDED), und neue Implementierungen dürfen (MUST NOT) diese Optimierung durchführen. Diese Optimierung stammt aus der Annahme, dass alle Interface-Adressen aus demselben Identifier generiert werden. Diese Annahme trifft jedoch tatsächlich nicht zu; es wurden neue Arten von Adressen eingeführt, bei denen die Interface Identifiers für alle Unicast-Adressen auf einer einzelnen Schnittstelle nicht notwendigerweise gleich sind [RFC4941] [RFC3972]. Die Anforderung, Duplicate Address Detection für alle Unicast-Adressen durchzuführen, macht den Algorithmus robust für aktuelle und zukünftige spezielle Interface Identifiers.

Das Verfahren zur Erkennung doppelter Adressen verwendet Neighbor Solicitation- und Advertisement-Nachrichten, wie unten beschrieben. Wenn während des Verfahrens eine doppelte Adresse entdeckt wird, kann die Adresse der Schnittstelle nicht zugewiesen werden. Wenn die Adresse von einem Interface Identifier abgeleitet ist, muss der Schnittstelle ein neuer Identifier zugewiesen werden, oder alle IP-Adressen für die Schnittstelle müssen manuell konfiguriert werden. Beachten Sie, dass das Verfahren zur Erkennung doppelter Adressen nicht vollständig zuverlässig ist und dass es immer noch möglich ist, dass doppelte Adressen existieren (z. B. wenn der Link während der Ausführung von Duplicate Address Detection partitioniert wurde).

Eine Adresse, auf die das Duplicate Address Detection-Verfahren angewendet wird, wird als tentativ bezeichnet, bis das Verfahren erfolgreich abgeschlossen ist. Eine tentative Adresse wird nicht als "einer Schnittstelle zugewiesen" im traditionellen Sinne betrachtet. Das heißt, die Schnittstelle muss Neighbor Solicitation- und Advertisement-Nachrichten akzeptieren, die die tentative Adresse im Target-Adressfeld enthalten, aber die Verarbeitung dieser Pakete unterscheidet sich von der Verarbeitung von Paketen, deren Zieladresse mit einer der Schnittstelle zugewiesenen Adresse übereinstimmt. Andere an die tentative Adresse gerichtete Pakete sollten stillschweigend verworfen werden. Beachten Sie, dass die "anderen Pakete" Neighbor Solicitation- und Advertisement-Nachrichten umfassen, die die tentative (d. h. Unicast-) Adresse als IP-Zieladresse und die tentative Adresse im Target-Adressfeld haben. Solche Nachrichten sollten jedoch im normalen Betrieb nicht auftreten, da diese Nachrichten im Duplicate Address Detection-Verfahren als Multicast gesendet werden.

Es sollte auch beachtet werden, dass Duplicate Address Detection durchgeführt werden muss, bevor die Adresse der Schnittstelle zugewiesen wird, um zu verhindern, dass mehrere Knoten dieselbe Adresse gleichzeitig verwenden. Wenn ein Knoten beginnt, eine Adresse parallel zur Ausführung von Duplicate Address Detection zu verwenden, und ein anderer Knoten die Adresse bereits verwendet, würde der Knoten, der Duplicate Address Detection durchführt, fälschlicherweise Datenverkehr verarbeiten, der an den anderen Knoten adressiert ist, was zu möglichen negativen Konsequenzen wie dem Zurücksetzen offener TCP-Verbindungen führt.

Die folgenden Unterabschnitte beschreiben die spezifischen Tests, die ein Knoten durchführt, um die Eindeutigkeit einer Adresse zu überprüfen. Wenn keiner der Tests das Vorhandensein einer doppelten Adresse innerhalb von RetransTimer Millisekunden nach dem Senden von DupAddrDetectTransmits Neighbor Solicitations anzeigt, wird die Adresse als eindeutig betrachtet. Sobald die Adresse als eindeutig bestimmt ist, kann sie der Schnittstelle zugewiesen werden.

5.4.1. Message Validation (Nachrichtenvalidierung)​

Ein Knoten muss (MUST) jede Neighbor Solicitation- oder Advertisement-Nachricht, die die in [RFC4861] angegebenen Gültigkeitsprüfungen nicht besteht, stillschweigend verwerfen. Eine Neighbor Solicitation- oder Advertisement-Nachricht, die diese Gültigkeitsprüfungen besteht, wird als gültige Solicitation bzw. gültiges Advertisement bezeichnet.

5.4.2. Sending Neighbor Solicitation Messages (Senden von Neighbor Solicitation-Nachrichten)​

Bevor eine Neighbor Solicitation gesendet wird, muss (MUST) eine Schnittstelle der All-Nodes-Multicast-Adresse und der Solicited-Node-Multicast-Adresse der tentativen Adresse beitreten. Ersteres stellt sicher, dass der Knoten Neighbor Advertisements von anderen Knoten empfängt, die die Adresse bereits verwenden; Letzteres stellt sicher, dass zwei Knoten, die gleichzeitig versuchen, dieselbe Adresse zu verwenden, die Anwesenheit des jeweils anderen erkennen sollten.

Um eine Adresse zu überprüfen, sendet ein Knoten DupAddrDetectTransmits Neighbor Solicitations, jede getrennt durch RetransTimer Millisekunden. Die Zieladresse der Solicitation wird auf die zu überprüfende Adresse gesetzt, die IP-Quelladresse wird auf die nicht spezifizierte Adresse gesetzt und die IP-Zieladresse wird auf die Solicited-Node-Multicast-Adresse der Zieladresse gesetzt.

Wenn die Neighbor Solicitation das erste Paket wäre, das von der Schnittstelle nach (Re-)Initialisierung der Schnittstelle gesendet würde, sollte (SHOULD) der Knoten das Beitreten zur Solicited-Node-Multicast-Adresse um eine zufällige Verzögerung zwischen 0 und MAX_RTR_SOLICITATION_DELAY, wie in [RFC4861] angegeben, verzögern. Dies hilft, Überlastungen zu mildern, wenn viele Knoten gleichzeitig auf einem Link starten (z. B. nach einem Stromausfall), und kann helfen, Wettlaufbedingungen zu vermeiden, wenn mehrere Knoten gleichzeitig versuchen, dieselbe Adresse zu erfragen.

Auch wenn die Neighbor Solicitation nicht das erste zu sendende Paket ist, sollte (SHOULD) der Knoten das Beitreten zur Solicited-Node-Multicast-Adresse um eine zufällige Verzögerung zwischen 0 und MAX_RTR_SOLICITATION_DELAY verzögern, wenn die zu überprüfende Adresse durch eine Router Advertisement-Nachricht konfiguriert wird, die an eine Multicast-Adresse gesendet wird. Die Verzögerung vermeidet ähnliche Überlastungen, wenn mehrere Knoten Adressen konfigurieren, indem sie dieselbe einzelne Multicast-Router-Advertisement empfangen.

Beachten Sie, dass ein Knoten beim Beitreten zu einer Multicast-Adresse normalerweise eine Multicast Listener Discovery (MLD)-Berichtsnachricht [RFC2710] [RFC3810] für die Multicast-Adresse sendet. Im Fall von Duplicate Address Detection ist der MLD-Bericht erforderlich, um MLD-lauschende Switches (nicht Router) zu informieren, Multicast-Pakete weiterzuleiten. In der obigen Beschreibung bedeutet die Verzögerung des Beitritts zur Multicast-Adresse daher, die Übertragung der entsprechenden MLD-Berichtsnachricht zu verzögern. Da die MLD-Spezifikation keine zufällige Verzögerung erfordert, um Wettlaufbedingungen zu vermeiden, würde eine Verzögerung nur der Neighbor Solicitation zu einer Überlastung der MLD-Berichtsnachrichten führen. Die Überlastung würde dann verhindern, dass MLD-lauschende Switches ordnungsgemäß funktionieren, und dadurch verhindern, dass Duplicate Address Detection funktioniert. Die Anforderung, die MLD-Berichtsverzögerung in diesem Fall einzuschließen, vermeidet diese Situation. [RFC3590] diskutiert auch einige Interaktionsprobleme zwischen Duplicate Address Detection und MLD und spezifiziert, welche Quelladresse für MLD-Berichte in diesem Fall verwendet werden sollte.

Um die Robustheit des Duplicate Address Detection-Algorithmus zu verbessern, muss (MUST) eine Schnittstelle während der Verzögerungsperiode Datagramme empfangen und verarbeiten, die an die All-Nodes-Multicast-Adresse oder an die Solicited-Node-Multicast-Adresse der tentativen Adresse gesendet werden. Dies steht nicht notwendigerweise im Widerspruch zur Anforderung, den Beitritt zur Multicast-Gruppe zu verzögern. Tatsächlich kann in einigen Fällen ein Knoten während der Verzögerungsperiode vor der MLD-Berichtsübertragung beginnen, auf die Gruppe zu lauschen. Es sollte jedoch beachtet werden, dass in einigen Link-Layer-Umgebungen, insbesondere mit MLD-lauschenden Switches, es nicht möglich sein wird, Multicast zu empfangen, bevor der MLD-Bericht gesendet wird.

5.4.3. Receiving Neighbor Solicitation Messages (Empfangen von Neighbor Solicitation-Nachrichten)​

Beim Empfang muss (MUST) ein Knoten prüfen, ob die Zieladresse oder die Quelladresse einer Neighbor Solicitation mit einer tentativen Adresse übereinstimmt. Bei einer Übereinstimmung bezieht sich die Neighbor Solicitation auf eine Adresse, für die Duplicate Address Detection durchgeführt wird. Die Verarbeitung unterscheidet sich je nachdem, ob die Zieladresse oder die Quelladresse übereinstimmt.

Wenn die Zieladresse mit der tentativen Adresse übereinstimmt:

Die Quelladresse der Neighbor Solicitation bezieht sich auf die IP-Quelladresse des Absenders. Wenn die IP-Quelladresse der Neighbor Solicitation die nicht spezifizierte Adresse (0:0:0:0:0:0:0:0) ist, führt die Quelle Duplicate Address Detection für diese Adresse durch, daher wurde die Neighbor Solicitation von Duplicate Address Detection gesendet. Andernfalls verwendet die Quelle die Adresse als Unicast-Adresse. In beiden Fällen zeigt die Neighbor Solicitation an, dass die tentative Adresse des Knotens dupliziert ist. Die Neighbor Solicitation zeigt an, dass der Absender der Neighbor Solicitation, der versucht zu überprüfen, dass die tentative Adresse des Knotens nicht dupliziert ist, dies nicht tun wird. Die Neighbor Solicitation zeigt an, dass die Adresse dupliziert ist.

Ein Knoten, der eine solche Neighbor Solicitation empfängt, darf (MUST NOT) ein Neighbor Advertisement senden (sonst ist die Adresse tentativ und sollte noch nicht (SHOULD NOT) verwendet werden). Stattdessen zeigt der Empfang einer solchen Neighbor Solicitation an, dass die zu überprüfende tentative Adresse dupliziert ist, daher muss (MUST) der Knoten den Prozess des Sendens von Neighbor Solicitations sofort stoppen.

Wenn die Quelladresse mit der tentativen Adresse übereinstimmt:

Dies zeigt an, dass ein anderer Knoten ebenfalls dieselbe Adresse als tentativ verwendet und gleichzeitig Duplicate Address Detection durchführt. Dies ist ein zu erwartendes Phänomen, wenn mehrere Schnittstellen gleichzeitig initialisiert werden (z. B. beim Systemstart). Der Empfang dieser Neighbor Solicitation zeigt jedoch an, dass die Adresse dupliziert ist, daher muss (MUST) der Knoten das Senden von Neighbor Solicitations sofort stoppen.

Ein Knoten kann eine Neighbor Solicitation empfangen, während die Neighbor Discovery läuft, aber nachdem er bereits das Senden gestoppt hat, bevor die Duplikation erkannt wurde. In diesem Fall sollte (SHOULD) die Neighbor Solicitation ignoriert werden (außer im Fall von Abschnitt 5.4.4).

5.4.4. Receiving Neighbor Advertisement Messages (Empfangen von Neighbor Advertisement-Nachrichten)​

Für Duplicate Address Detection (DAD) muss (MUST) ein Knoten prüfen, ob die Zieladresse der Neighbor Solicitation mit einer tentativen Adresse übereinstimmt und ob die Zieladresse des Neighbor Advertisements mit der tentativen Adresse übereinstimmt. Wenn sie übereinstimmt, zeigt das Neighbor Advertisement an, dass die Adresse dupliziert ist. Wenn sie nicht übereinstimmt, ist das Advertisement nicht relevant.

Beim Empfang eines Neighbor Advertisements mit einer Zieladresse, die mit einer tentativen Adresse übereinstimmt, muss (MUST) ein Knoten das Senden von Neighbor Solicitations stoppen und erkennt, dass die Adresse auf dem Link verwendet wird.

5.4.5. When Duplicate Address Detection Fails (Wenn Duplicate Address Detection fehlschlägt)​

Eine tentative Adresse, die wie oben beschrieben als dupliziert bestimmt wurde, darf (MUST NOT) einer Schnittstelle zugewiesen werden, und der Knoten sollte (SHOULD) einen Systemverwaltungsfehler protokollieren.

Wenn die Adresse eine Link-Local-Adresse ist, die aus einem Interface Identifier gebildet wurde, der auf einer Hardware-Adresse basiert, die eindeutig zugewiesen werden sollte (z. B. ein EUI-64 für eine Ethernet-Schnittstelle), sollten (SHOULD) die IP-Operationen auf der Schnittstelle deaktiviert werden. Durch Deaktivierung der IP-Operationen wird der Knoten:

  • Keine IP-Pakete von der Schnittstelle senden,
  • Alle auf der Schnittstelle empfangenen IP-Pakete stillschweigend verwerfen, und
  • Keine IP-Pakete zur Schnittstelle weiterleiten (wenn er als Router fungiert oder Pakete mit einem Routing-Header verarbeitet).

In diesem Fall kann die IP-Adressduplikation bedeuten, dass eine duplizierte Hardware-Adresse verwendet wird, und der Versuch, durch Konfiguration einer anderen IP-Adresse wiederherzustellen, wird nicht zu einem nutzbaren Netzwerk führen. Tatsächlich kann es die Situation verschlimmern, indem es Probleme schafft, die schwieriger zu diagnostizieren sind, als einfach die Netzwerkoperationen auf der Schnittstelle zu deaktivieren; der Benutzer wird ein teilweise funktionierendes Netzwerk sehen, bei dem einige Dinge funktionieren und andere nicht.

Andererseits, wenn die duplizierte Link-Local-Adresse nicht aus einem Interface Identifier gebildet wurde, der auf einer Hardware-Adresse basiert, die eindeutig zugewiesen werden sollte, können (MAY) die IP-Operationen auf der Schnittstelle fortgesetzt werden.

Hinweis: Wie in Abschnitt 2 angegeben, bedeutet "IP" in der obigen Beschreibung "IPv6". Obwohl die Hintergrundrational bezüglich Hardware-Adressen unabhängig von einem bestimmten Netzwerkprotokoll ist, liegen ihre Auswirkungen auf andere Protokolle außerhalb des Anwendungsbereichs dieses Dokuments.

5.5. Creation of Global Addresses (Erstellung von globalen Adressen)​

Globale Adressen werden gebildet, indem ein Interface Identifier an ein Präfix geeigneter Länge angehängt wird. Die Präfixe werden aus Prefix Information-Optionen erhalten, die in Router Advertisements enthalten sind. Die in diesem Abschnitt beschriebene Erstellung globaler Adressen sollte (SHOULD) lokal konfigurierbar sein. Die unten beschriebene Verarbeitung muss (MUST) jedoch standardmäßig aktiviert sein.

5.5.1. Soliciting Router Advertisements (Anfordern von Router Advertisements)​

Router Advertisements werden periodisch an die All-Nodes-Multicast-Adresse gesendet. Um schnell ein Advertisement zu erhalten, sendet ein Host eine Router Solicitation, wie in [RFC4861] beschrieben.

5.5.2. Absence of Router Advertisements (Fehlen von Router Advertisements)​

Selbst wenn keine Router auf dem Link vorhanden sind, kann ein DHCPv6-Dienst zum Abrufen von Adressen weiterhin verfügbar sein, und ein Host möchte möglicherweise diesen Dienst nutzen. Aus Sicht der Autokonfiguration gibt es keine Router auf dem Link, wenn nach dem Senden einiger Router Solicitations (wie in [RFC4861] beschrieben) keine Router Advertisements empfangen werden.

Beachten Sie, dass in diesem Sinne möglicherweise keine Router auf dem Link vorhanden sind, es jedoch einen Knoten mit der Fähigkeit zum Weiterleiten von Paketen geben kann. In diesem Fall muss die Adresse des Weiterleitungsknotens manuell im Host konfiguriert werden, um Off-Link-Pakete zu senden, da der einzige Mechanismus zur Autokonfiguration der Standard-Router-Adresse der Mechanismus der Router Advertisements ist.

5.5.3. Router Advertisement Processing (Router Advertisement-Verarbeitung)​

Für jede Prefix Information-Option in einem Router Advertisement:

a) Wenn das Autonome Flag nicht gesetzt ist, die Prefix Information-Option stillschweigend ignorieren.

b) Wenn das Präfix das Link-Local-Präfix ist, die Prefix Information-Option stillschweigend ignorieren.

c) Wenn die bevorzugte Lebensdauer größer als die gültige Lebensdauer ist, die Prefix Information-Option stillschweigend ignorieren. In diesem Fall kann (MAY) ein Knoten einen Systemverwaltungsfehler protokollieren wollen.

d) Wenn das angekündigte Präfix nicht gleich dem Präfix einer Stateless Autoconfiguration-Adresse ist, die bereits in der mit der Schnittstelle verbundenen Liste vorhanden ist (wobei "gleich" bedeutet, dass beide Präfixlängen gleich sind und die Präfixlängen-Bits des Präfixes identisch sind), und wenn die gültige Lebensdauer nicht Null ist, eine Adresse bilden (und zur Liste hinzufügen), indem das angekündigte Präfix mit dem Interface Identifier des Links wie folgt kombiniert wird:

|            128 - N bits               |       N bits           |
+---------------------------------------+------------------------+
|            link prefix                |  interface identifier  |
+----------------------------------------------------------------+

Wenn die Summe aus Präfixlänge und Interface Identifier-Länge nicht gleich 128 Bits ist, muss (MUST) die Prefix Information-Option ignoriert werden. In diesem Fall kann (MAY) eine Implementierung einen Systemverwaltungsfehler protokollieren wollen. Die Länge des Interface Identifiers ist in einem separaten link-typ-spezifischen Dokument definiert, das auch mit der Adressarchitektur [RFC4291] konsistent sein sollte (siehe Abschnitt 2).

Es liegt in der Verantwortung des Systemadministrators sicherzustellen, dass die Länge der in Router Advertisements enthaltenen Präfixe mit der Länge des Interface Identifiers für diesen Link-Typ übereinstimmt. Es sollte jedoch beachtet werden, dass dies nicht bedeutet, dass die angekündigte Präfixlänge bedeutungslos ist. Tatsächlich hat die angekündigte Länge eine nichttriviale Bedeutung für die On-Link-Bestimmung in [RFC4861], wo die Summe aus Präfixlänge und Interface Identifier-Länge möglicherweise nicht gleich 128 ist. Daher sollte es sicher sein, die angekündigte Präfixlänge hier zu validieren, um Konfigurationsfehler zu erkennen und zu vermeiden, die ungültige Präfixlängen im Kontext der Adressautokonfiguration spezifizieren.

Beachten Sie, dass zukünftige Versionen der Adressarchitektur [RFC4291] und zukünftige link-typ-spezifische Dokumente (die immer noch miteinander konsistent sein werden) Interface Identifiers von Längen zulassen können, die sich von den in den aktuellen Dokumenten definierten Werten unterscheiden. Daher sollten (SHOULD NOT) Implementierungen nicht eine bestimmte Konstante annehmen. Stattdessen sollten sie Interface Identifiers beliebiger Länge erwarten.

Wenn die Adresse erfolgreich gebildet wird und noch nicht in der Liste ist, fügt der Host sie zur Liste der der Schnittstelle zugewiesenen Adressen hinzu und initialisiert ihre bevorzugten und gültigen Lebensdauerwerte aus der Prefix Information-Option. Beachten Sie, dass die am Anfang dieses Schritts durchgeführte Prüfung des Präfixes nicht immer Adresskonflikte in der Liste erkennt. Es ist möglich, dass eine bereits in der Liste vorhandene Adresse (durch manuelle Konfiguration oder DHCPv6-Konfiguration) zufällig identisch mit der neu erstellten Adresse ist, und dies sollte eine untypische Situation sein.

e) Wenn das angekündigte Präfix gleich dem Präfix einer Adresse in der Liste ist, die durch Stateless Autoconfiguration konfiguriert wurde, wird die bevorzugte Lebensdauer der Adresse auf die bevorzugte Lebensdauer im empfangenen Advertisement zurückgesetzt. Die spezifische Operation, die für die gültige Lebensdauer der Adresse durchgeführt wird, hängt von der gültigen Lebensdauer im empfangenen Advertisement und der verbleibenden Zeit ab, bis die gültige Lebensdauer der zuvor autokonfigurierten Adresse abläuft. In der folgenden Diskussion werden wir die verbleibende Zeit als "RemainingLifetime" bezeichnen:

  1. Wenn die empfangene gültige Lebensdauer größer als 2 Stunden oder größer als RemainingLifetime ist, die gültige Lebensdauer der entsprechenden Adresse auf die angekündigte gültige Lebensdauer setzen.
  2. Wenn RemainingLifetime kleiner oder gleich 2 Stunden ist, die Prefix Information-Option bezüglich der gültigen Lebensdauer ignorieren, es sei denn, das Router Advertisement, von dem diese Option erhalten wurde, wurde authentifiziert (z. B. über Secure Neighbor Discovery [RFC3971]). Wenn das Router Advertisement authentifiziert wurde, sollte (SHOULD) die gültige Lebensdauer der entsprechenden Adresse auf die gültige Lebensdauer in der empfangenen Option gesetzt werden.
  3. Andernfalls die gültige Lebensdauer der entsprechenden Adresse auf 2 Stunden zurücksetzen.

Die obigen Regeln behandeln einen spezifischen Denial-of-Service-Angriff, bei dem gefälschte Advertisements Präfixe mit sehr kurzen gültigen Lebenszeiten enthalten könnten. Ohne die obigen Regeln könnte ein einzelnes nicht authentifiziertes Advertisement, das eine gefälschte Prefix Information-Option mit kurzer gültiger Lebensdauer enthält, dazu führen, dass alle Adressen eines Knotens vorzeitig ablaufen. Die obigen Regeln stellen sicher, dass legitime Advertisements (die periodisch gesendet werden) sie "aufheben", bevor die kurze gültige Lebensdauer tatsächlich wirksam wird.

Beachten Sie, dass die bevorzugte Lebensdauer der entsprechenden Adresse immer auf die bevorzugte Lebensdauer in der empfangenen Prefix Information-Option zurückgesetzt wird, unabhängig davon, ob die gültige Lebensdauer zurückgesetzt oder ignoriert wird. Der Unterschied ergibt sich aus der Tatsache, dass mögliche Angriffe auf die bevorzugte Lebensdauer relativ gering sind. Darüber hinaus ist es nicht einmal wünschenswert, die bevorzugte Lebensdauer zu ignorieren, wenn ein legitimer Administrator eine bestimmte Adresse durch Senden einer kurzen bevorzugten Lebensdauer veralten lassen möchte (und die gültige Lebensdauer versehentlich ignoriert wird).

5.5.4. Address Lifetime Expiry (Ablauf der Adresslebensdauer)​

Wenn die bevorzugte Lebensdauer einer bevorzugten Adresse abläuft, wird die bevorzugte Adresse veraltet. Eine veraltete Adresse sollte (SHOULD) weiterhin als Quelladresse in bestehenden Kommunikationen verwendet werden, sollte jedoch nicht (SHOULD NOT) verwendet werden, um neue Kommunikationen zu initiieren, wenn eine alternative (nicht veraltete) Adresse mit ausreichendem Geltungsbereich leicht verwendet werden kann.

Beachten Sie, dass die Durchführbarkeit der Verwendung einer nicht veralteten Adresse zur Initiierung neuer Kommunikationen möglicherweise eine anwendungsspezifische Entscheidung ist, da nur die Anwendung wissen kann, ob die (jetzt) veraltete Adresse (oder immer noch) von der Anwendung verwendet wird. Wenn beispielsweise eine Anwendung dem Protokollstapel explizit angibt, die veraltete Adresse als Quelladresse zu verwenden, muss der Protokollstapel sie akzeptieren; die Anwendung kann dies anfordern, weil diese IP-Adresse in der Kommunikation auf höherer Ebene verwendet wird und möglicherweise erfordert, dass mehrere Verbindungen in solchen Paketen dasselbe IP-Adresspaar verwenden.

IP und höhere Schichten (z. B. TCP, UDP) müssen (MUST) weiterhin Datagramme akzeptieren und verarbeiten, die an eine veraltete Adresse gesendet werden, da eine veraltete Adresse immer noch eine gültige Adresse für die Schnittstelle ist. Im Fall von TCP bedeutet dies, auf ein TCP-SYN-Segment zu antworten, das an eine veraltete Adresse gesendet wird, indem die veraltete Adresse als Quelladresse im entsprechenden SYN-ACK verwendet wird (wenn diese Verbindung erlaubt wird).

Implementierungen können (MAY) verhindern, dass neue Kommunikationen eine veraltete Adresse verwenden, aber die Systemverwaltung muss (MUST) die Möglichkeit haben, eine solche Einrichtung zu deaktivieren, und diese Einrichtung muss (MUST) standardmäßig deaktiviert sein.

Es sollten auch andere subtile Fälle der Quell-Adressenauswahl beachtet werden. Beispielsweise klärt die obige Beschreibung nicht, welche Adresse zwischen einer veralteten Adresse mit kleinerem Geltungsbereich und einer nicht veralteten Adresse mit ausreichendem Geltungsbereich verwendet werden sollte. Die Details der Adressenauswahl einschließlich dieses Falls werden in [RFC3484] beschrieben und liegen außerhalb des Anwendungsbereichs dieses Dokuments.

Wenn die gültige Lebensdauer einer Adresse (und ihrer Zuordnung zu einer Schnittstelle) abläuft, wird die Adresse ungültig. Eine ungültige Adresse darf (MUST NOT) als Quelladresse in ausgehenden Kommunikationen verwendet werden und darf (MUST NOT) auf der empfangenden Schnittstelle als Ziel erkannt werden.

5.6. Configuration Consistency (Konfigurationskonsistenz)​

Ein Host kann gleichzeitig Stateless Autoconfiguration und DHCPv6 verwenden, um Adressinformationen zu erhalten, da beide gleichzeitig aktiviert sein können. Die Werte anderer Konfigurationsparameter (wie MTU-Größe und Hop-Limit) können auch aus Router Advertisements und DHCPv6 gelernt werden. Wenn dieselben Konfigurationsinformationen von mehreren Quellen bereitgestellt werden, sollten die Werte dieser Informationen konsistent sein. Wenn jedoch von mehreren Quellen empfangene Informationen nicht konsistent sind, wird dies nicht als fataler Fehler betrachtet. Ein Host akzeptiert die Vereinigung aller über Neighbor Discovery und DHCPv6 empfangenen Informationen.

Wenn inkonsistente Informationen aus verschiedenen Quellen gelernt werden, möchten Implementierungen möglicherweise Informationen bevorzugen, die sicher gelernt wurden, gegenüber Informationen, die ohne Schutz gelernt wurden. Beispielsweise diskutiert Abschnitt 8 von [RFC3971], wie Konflikte zwischen Informationen behandelt werden, die über Secure Neighbor Discovery gelernt wurden, und solchen, die über gewöhnliche Neighbor Discovery gelernt wurden. Dieselbe Diskussion kann auf die Präferenz zwischen Informationen angewendet werden, die über gewöhnliche Neighbor Discovery gelernt wurden, und solchen, die über sicheres DHCPv6 gelernt wurden, usw.

In jedem Fall sollten (SHOULD) bei fehlenden Sicherheitsunterschieden die zuletzt erhaltenen Werte gegenüber früher gelernten Informationen bevorzugt werden.

5.7. Retaining Configured Addresses for Stability (Behalten konfigurierter Adressen zur Stabilität)​

Implementierungen mit stabilem Speicher möchten möglicherweise Adressen im Speicher behalten, wenn Adressen über Stateless Address Autoconfiguration abgerufen werden. Unter der Annahme, dass die verwendeten Lebenszeiten vernünftig sind, bedeutet diese Technik, dass eine temporäre Unterbrechung der Router (von weniger als der gültigen Lebensdauer) niemals den Verlust der globalen Adresse eines Knotens verursachen wird, selbst wenn der Knoten neu starten sollte. Bei Verwendung dieser Technik sollte auch beachtet werden, dass die Ablaufzeiten der bevorzugten und gültigen Lebenszeiten beibehalten werden müssen, um die Verwendung der Adresse zu verhindern, nachdem die Adresse veraltet oder ungültig geworden ist.

Weitere Details zu dieser Erweiterung liegen außerhalb des Anwendungsbereichs dieses Dokuments.

Letztes Update am