8. Verhalten ersetzbarer Funktionen

Normalerweise werden in einem 6LoWPAN-Multi-Hop-Netzwerk die RA-Nachrichten verwendet, um Präfixe und Kontextinformationen an alle 6LRs in einer Route-Over-Topologie zu verteilen. Wenn alle Router so konfiguriert sind, dass sie einen Ersatzmechanismus für eine solche Informationsverteilung verwenden, unterliegt jede verbleibende Verwendung der 6LoWPAN-ND-Mechanismen der Ersatzspezifikation.

Es gibt auch die Möglichkeit für einen 6LR, Multi-Hop-DAD (für IPv6-Adressen, die nicht von einer EUI-64 abgeleitet sind) gegen einen 6LBR in einer Route-Over-Topologie unter Verwendung der DAR- und DAC-Nachrichten durchzuführen. Dies ist ersetzbar, da es andere Möglichkeiten geben könnte, entweder eine eindeutige Adresse zuzuweisen, wie z. B. DHCPv6 [RFC3315], oder andere zukünftige Mechanismen für Multi-Hop-DAD zu verwenden. Auch in diesem Fall unterliegt jede verbleibende Verwendung der 6LoWPAN-ND-Mechanismen der Ersatzspezifikation.

Um es klarzustellen: Implementierungen MÜSSEN die in den Abschnitten 8.1 und 8.2 beschriebenen Funktionen unterstützen, es sei denn, die Implementierung unterstützt eine Alternative ("Ersatz") aus einer anderen Spezifikation.

8.1. Multi-Hop-Präfix- und Kontextverteilung

Die Multi-Hop-Verteilung beruht auf RS-Nachrichten und RA-Nachrichten, die zwischen Routern gesendet werden, und verwendet die ABRO-Versionsnummer, um die Ausbreitung der Informationen (Präfixe und Kontextinformationen) zu steuern, die in den RAs gesendet werden.

Dieser Multi-Hop-Verteilungsmechanismus kann beliebige Informationen von einer beliebigen Anzahl von 6LBRs handhaben. Die Semantik der Kontextinformationen erfordert jedoch, dass alle 6LNs dieselben Informationen verwenden, unabhängig davon, ob sie komprimierte Pakete senden, weiterleiten oder empfangen. Somit muss der Manager der 6LBRs irgendwie sicherstellen, dass die Kontextinformationen über die 6LBRs hinweg synchron sind. Dies kann auf verschiedene Weise gehandhabt werden. Eine mögliche Art, dies sicherzustellen, besteht darin, die Kontext- und Präfixinformationen so zu behandeln, als stammten sie von einer logischen oder virtuellen Quelle, was im Wesentlichen bedeutet, dass es so aussieht, als würden die Informationen von einer einzigen Quelle verteilt.

Wenn sich ein Satz von 6LBRs wie ein einziger verhält (unter Verwendung von Mechanismen außerhalb des Geltungsbereichs dieses Dokuments), so dass die Präfixe und Kontexte und die ABRO-Versionsnummer von allen 6LBRs gleich sind, dann können diese 6LBRs eine einzelne IP-Adresse wählen, die in der ABRO verwendet wird.

8.1.1. 6LBRs senden Router-Advertisements

6LBRs, die Multi-Hop-Präfix- und Kontextverteilung unterstützen, MÜSSEN in jeder ihrer RAs eine ABRO enthalten. Das ABRO-Versionsnummer-Feld wird verwendet, um Präfix- und Kontextinformationen im gesamten LoWPAN konsistent zu halten, zusammen mit den Richtlinien in Abschnitt 7.2. Jedes Mal, wenn sich Informationen im Satz von PIOs oder 6COs ändern, wird die ABRO-Version um eins erhöht.

Dies erfordert, dass der 6LBR die PIO, 6CO und ABRO-Versionsnummer in einem stabilen Speicher verwaltet, da eine alte Versionsnummer von den 6LRs stillschweigend ignoriert wird.

8.1.2. Router senden Router-Solicitations

In einem 6LoWPAN erfolgt die Multi-Hop-Verteilung, sofern nicht ersetzt, unter Verwendung von RA-Nachrichten. Daher MUSS ein Router (6LR) bei der Schnittstelleninitialisierung RS-Nachrichten gemäß den für Hosts in [RFC4861] festgelegten Regeln senden. Dies wiederum veranlasst die Router, mit RA-Nachrichten zu antworten, die dann verwendet werden können, um die Präfix- und Kontextinformationen anfänglich zu säen.

8.1.3. Router verarbeiten Router-Advertisements

Wenn die Multi-Hop-Verteilung nicht unter Verwendung von RA-Nachrichten erfolgt, folgen die Router [RFC4861], was besagt, dass sie lediglich einige Konsistenzprüfungen durchführen; in diesem Fall gilt nichts in Abschnitt 8.1. Andernfalls prüfen und zeichnen die Router die Präfix- und Kontextinformationen aus den empfangenen RAs auf und verwenden diese Informationen wie folgt.

Wenn eine empfangene RA keine ABRO enthält, MUSS die RA stillschweigend ignoriert werden.

Der Router verwendet das 6LBR-Adressfeld in der ABRO, um zu prüfen, ob er zuvor Informationen von dem 6LBR empfangen hat. Wenn er keine solchen Informationen findet, zeichnet er nur die 6LBR-Adresse, Version, gültige Lebensdauer und die zugehörigen Präfixe und Kontextinformationen auf. Wenn der 6LBR bereits bekannt ist, MUSS das Versionsnummer-Feld mit der aufgezeichneten Versionsnummer für diesen 6LBR verglichen werden. Wenn die im Paket empfangene Versionsnummer kleiner als die gespeicherte Versionsnummer ist, werden die Informationen in der RA stillschweigend ignoriert. Andernfalls werden die aufgezeichneten Informationen und die Versionsnummer aktualisiert.

8.1.4. Speichern der Informationen

Der Router hält den Status für jeden 6LBR, den er mit einer ABRO sieht. Dies umfasst die Versionsnummer, die gültige Lebensdauer und den vollständigen Satz von PIOs und 6COs. Die Präfixe laufen basierend auf der gültigen Lebensdauer in der PIO ab. Das Kontext-Präfix läuft basierend auf der gültigen Lebensdauer in der 6CO ab.

Während die Präfixe und Kontextinformationen im Router gespeichert sind, werden ihre gültigen und bevorzugten Lebensdauern im Laufe der Zeit verringert. Dies stellt sicher, dass, wenn der Router diese Informationen später wiederum in den von ihm gesendeten RAs ankündigt, die 'Ablaufzeit' nicht versehentlich weiter in die Zukunft verschoben wird. Wenn beispielsweise eine 6CO mit einer gültigen Lebensdauer von 10 Minuten zum Zeitpunkt T empfangen wird und der Router diese in eine RA aufnimmt, die er zum Zeitpunkt T+5 Minuten sendet, beträgt die gültige Lebensdauer in der von ihm gesendeten 6CO nur 5 Minuten.

8.1.5. Senden von Router-Advertisements

Wenn die Multi-Hop-Verteilung unter Verwendung von RA-Nachrichten durchgeführt wird, MÜSSEN die Router sicherstellen, dass die ABRO immer mit den Präfixen und Kontextinformationen zusammenbleibt, die mit dieser ABRO empfangen wurden. Wenn der Router also Präfix P1 mit einer ABRO empfangen hat, die besagt, dass es von einem 6LBR stammt, und Präfix P2 von einem anderen 6LBR, dann DARF der Router die beiden Präfixe NICHT in dieselbe RA-Nachricht aufnehmen. Präfix P1 MUSS in einer RA sein, die eine ABRO vom ersten 6LBR enthält, usw. Beachten Sie, dass mehrere 6LBRs möglicherweise dieselben Präfix- und Kontextinformationen ankündigen, diese aber dennoch den 6LBRs zugeordnet werden müssen, die sie angekündigt haben.

Die Router senden regelmäßig RAs wie in [RFC4861]. Dies dient dem Nutzen der anderen Router, die die Präfixe und Kontextinformationen empfangen. Die Router antworten auch auf RSs, indem sie RA-Nachrichten per Unicast senden. In beiden Fällen gilt die oben genannte Einschränkung, die ABRO mit 'ihren' Präfixen und Kontextinformationen zusammenzuhalten.

Wenn ein Router neue Informationen von einem 6LBR empfängt, d. h. entweder von einem neuen 6LBR hört (eine neue 6LBR-Adresse in der ABRO) oder die ABRO-Versionsnummer eines bestehenden 6LBR gestiegen ist, dann ist es nützlich, einige ausgelöste Aktualisierungen zu senden. Die Empfehlung ist, sich genauso zu verhalten wie wenn eine Schnittstelle zu einer Advertising-Schnittstelle geworden ist, wie in [RFC4861] beschrieben, d. h. bis zu drei RA-Nachrichten zu senden. Dies stellt eine schnelle Ausbreitung neuer Informationen an alle 6LRs sicher.

8.2. Multi-Hop-Duplikat-Adresserkennung

Die ARO kann zusätzlich zur Registrierung einer Adresse in einem 6LR verwendet werden, um den 6LR überprüfen zu lassen, ob die Adresse nicht von einem anderen dem 6LR bekannten Host verwendet wird. Das reicht jedoch in einer Route-Over-Topologie (oder in einem LoWPAN mit mehreren 6LBRs) nicht aus, da ein Host, der an einen anderen 6LR angeschlossen ist, dieselbe Adresse verwenden könnte. Es könnte in Zukunft verschiedene Möglichkeiten für die 6LRs geben, eine solche Duplikat-Adresserkennung zu koordinieren, oder Adressen könnten unter Verwendung eines DHCPv6-Servers zugewiesen werden, der die Eindeutigkeit als Teil der Zuweisung überprüft.

Diese Spezifikation bietet eine ersetzbare einfache Technik für 6LRs und 6LBRs zur Durchführung von DAD, die die Informationen aus der ARO in den DAR- und DAC-Nachrichten wiederverwendet. Diese Technik wird nicht benötigt, wenn die Schnittstellen-ID in der Adresse auf einer EUI-64 basiert, da angenommen wird, dass diese global eindeutig sind. Die Technik geht davon aus, dass sich entweder die 6LRs bei allen 6LBRs registrieren oder das Netzwerk einen Mechanismus außerhalb des Geltungsbereichs verwendet, um die DAD-Tabellen in den 6LBRs synchron zu halten.

Der Multi-Hop-DAD-Mechanismus wird synchron verwendet, wenn eine Adresse zum ersten Mal bei einem bestimmten 6LR registriert wird. Das heißt, die ARO wird erst an den Host zurückgegeben, wenn Multi-Hop-DAD gegen die 6LBRs abgeschlossen ist. Für bestehende Registrierungen im 6LR muss Multi-Hop-DAD gegen die 6LBRs wiederholt werden, um sicherzustellen, dass der Eintrag für die Adresse in den 6LBRs nicht abläuft, aber das kann asynchron zur Antwort an die Hosts erfolgen. Eine Methode, dies zu erreichen, besteht darin, zu verfolgen, wie viel von der Lebensdauer übrig ist, die der 6LR bei den 6LBRs registriert hat, und sich erneut beim 6LBR zu registrieren, wenn diese Lebensdauer kurz vor dem Ablauf steht.

Für synchrones Multi-Hop-DAD führt der 6LR einige zusätzliche Prüfungen durch, um sicherzustellen, dass er einen NCE hat, den er verwenden kann, um dem Host zu antworten, wenn er eine Antwort von einem 6LBR empfängt. Dies besteht darin, auf einen bereits existierenden (vorläufigen oder registrierten) NCE für die registrierte Adresse mit einer anderen EUI-64 zu prüfen. Wenn ein solcher registrierter NCE existiert, dann SOLLTE der 6LR antworten, dass die Adresse ein Duplikat ist. Wenn ein solcher vorläufiger NCE existiert, dann SOLLTE der 6LR die ARO stillschweigend ignorieren und sich darauf verlassen, dass der Host die ARO erneut überträgt. Dies ist erforderlich, um den Fall zu behandeln, wenn mehrere Hosts gleichzeitig versuchen, dieselbe IPv6-Adresse zu registrieren. Wenn kein NCE existiert, MUSS der 6LR einen vorläufigen NCE mit der EUI-64 und der SLLAO erstellen. Dieser Eintrag wird verwendet, um die Antwort an den Host zu senden, wenn der 6LBR positiv antwortet.

Wenn ein 6LR eine NS empfängt, die eine ARO mit einer Registrierungslebensdauer ungleich Null enthält, und er keinen existierenden registrierten NCE hat, dann wird der 6LR mit diesem Mechanismus synchrones Multi-Hop-DAD aufrufen.

Der 6LR sendet eine DAR-Nachricht per Unicast an einen oder mehrere 6LBRs, wobei die DAR die Adresse des Hosts im Feld Registrierte Adresse enthält. Die DAR wird von 6LRs weitergeleitet, bis sie den 6LBR erreicht; daher wird ihr IPv6-Hop-Limit-Feld nicht 255 sein, wenn sie vom 6LBR empfangen wird. Der 6LBR antwortet mit einer DAC-Nachricht, die ein Hop-Limit von weniger als 255 haben wird, wenn sie den 6LR erreicht.

Wenn der 6LR die DAC vom 6LBR empfängt, sucht er nach einem übereinstimmenden (gleiche IP-Adresse und EUI-64) (vorläufigen oder registrierten) NCE. Wenn kein solcher Eintrag gefunden wird, wird die DAC stillschweigend ignoriert. Wenn ein Eintrag gefunden wird und die DAC Status=0 hatte, markiert der 6LR den vorläufigen NCE als registriert. In allen Fällen, wenn ein Eintrag gefunden wird, antwortet der 6LR dem Host mit einer NA, wobei die Status- und EUI-64-Felder aus der DAC in eine ARO in der NA kopiert werden. Falls der Status ein Fehler ist, wird die Ziel-IP-Adresse der NA aus dem EUI-64-Feld der DAC abgeleitet.

Ein vorläufiger NCE SOLLTE TENTATIVE_NCE_LIFETIME Sekunden nach seiner Erstellung ablaufen, um einem anderen Host zu ermöglichen, zu versuchen, die IPv6-Adresse zu registrieren.

8.2.1. Nachrichtenvalidierung für DAR und DAC

Ein Knoten MUSS alle empfangenen DAR- und DAC-Nachrichten stillschweigend verwerfen, für die mindestens eine der folgenden Gültigkeitsprüfungen nicht erfüllt ist:

• Wenn die Nachricht einen IP-Authentifizierungs-Header enthält, authentifiziert sich die Nachricht korrekt.
• ICMP-Prüfsumme ist gültig.
• ICMP-Code ist 0.
• ICMP-Länge (abgeleitet von der IP-Länge) ist 32 oder mehr Bytes.
• Die registrierte Adresse ist keine Multicast-Adresse.
• Alle enthaltenen Optionen haben eine Länge größer als Null.
• Die IP-Quelladresse ist nicht die unspezifizierte Adresse, noch ist sie eine Multicast-Adresse.

Der Inhalt des Reserviert-Feldes und aller nicht erkannten Optionen MUSS ignoriert werden. Zukünftige abwärtskompatible Änderungen am Protokoll können den Inhalt des Reserviert-Feldes spezifizieren oder neue Optionen hinzufügen; nicht abwärtskompatible Änderungen können andere Code-Werte verwenden.

Beachten Sie, dass aufgrund der Weiterleitung der DAR- und DAC-Nachrichten zwischen dem 6LR und 6LBR keine Hop-Limit-Prüfung beim Empfang für diese ICMPv6-Nachrichtentypen erfolgt.

8.2.2. Konzeptionelle Datenstrukturen

Ein 6LBR, der Multi-Hop-DAD implementiert, muss einen Zustand getrennt vom Neighbor Cache verwalten. Wir nennen diese konzeptionelle Datenstruktur die DAD-Tabelle. Sie wird durch die IPv6-Adresse indiziert – die registrierte Adresse in der DAR – und enthält die EUI-64 und die Registrierungslebensdauer des Hosts, der diese Adresse verwendet.

8.2.3. 6LR sendet eine Duplikat-Adressanforderung

Wenn ein 6LR, der Multi-Hop-DAD implementiert, eine NS von einem Host empfängt und vorbehaltlich der oben genannten Prüfungen, bildet und sendet der 6LR eine DAR an mindestens einen 6LBR. Die DAR enthält die folgenden Informationen:

• In der IPv6-Quelladresse eine globale Adresse des 6LR.
• In der IPv6-Zieladresse die Adresse des 6LBR.
• Im IPv6-Hop-Limit MULTIHOP_HOPLIMIT.
• Das Statusfeld MUSS auf Null gesetzt werden.
• Die EUI-64 und Registrierungslebensdauer werden aus der vom Host empfangenen ARO kopiert.
• Die registrierte Adresse wird auf die IPv6-Adresse des Hosts gesetzt, das heißt, den Absender der auslösenden NS.

Wenn ein 6LR eine NS von einem Host mit einer Registrierungslebensdauer von Null empfängt, wird zusätzlich zum Entfernen des NCE für den Host wie in Abschnitt 6 angegeben eine DAR an die 6LBRs wie oben gesendet.

Ein Router DARF den Neighbor Cache NICHT als Ergebnis des Empfangs einer DAR ändern.

8.2.4. 6LBR empfängt eine Duplikat-Adressanforderung

Wenn ein 6LBR, der das ersetzbare Multi-Hop-DAD implementiert, eine DAR von einem 6LR empfängt, führt er die in Abschnitt 8.2.1 angegebene Nachrichtenvalidierung durch. Wenn die DAR gültig ist, sucht der 6LBR nach der Registrierungsadresse in der DAD-Tabelle. Wenn ein Eintrag gefunden wird und die aufgezeichnete EUI-64 sich von der EUI-64 in der DAR unterscheidet, gibt er eine DAC NA mit dem Status 1 ('Duplikat-Adresse') zurück. Andernfalls gibt er eine DAC mit dem Status Null zurück und aktualisiert die Lebensdauer.

Wenn kein Eintrag in der DAD-Tabelle gefunden wird und die Registrierungslebensdauer ungleich Null ist, wird ein Eintrag erstellt und die EUI-64 und registrierte Adresse aus der DAR werden in diesem Eintrag gespeichert.

Wenn ein Eintrag in der DAD-Tabelle gefunden wird, die EUI-64 übereinstimmt und die Registrierungslebensdauer Null ist, wird der Eintrag aus der Tabelle gelöscht.

In beiden oben genannten Fällen bildet der 6LBR eine DAC mit den aus der DAR kopierten Informationen und das Statusfeld wird auf Null gesetzt. Die DAC wird an den 6LR zurückgesendet, d. h. zurück zur Quelle der DAR. Das IPv6-Hop-Limit wird auf MULTIHOP_HOPLIMIT gesetzt.

8.2.5. Verarbeitung einer Duplikat-Adressbestätigung

Wenn ein 6LR, der Multi-Hop-DAD implementiert, eine DAC-Nachricht empfängt, validiert er zuerst die Nachricht gemäß Abschnitt 8.2.1. Bei einer gültigen DAC wird die DAC stillschweigend ignoriert, wenn es keinen vorläufigen NCE gibt, der mit der registrierten Adresse und EUI-64 übereinstimmt. Andernfalls werden die Informationen in der DAC und im vorläufigen NCE verwendet, um eine NA zu bilden, die an den Host gesendet wird. Der Statuscode wird aus der DAC in die ARO kopiert, die an den Host gesendet wird. Falls die DAC einen Fehler anzeigt (der Status ist ungleich Null), wird die NA an den Host zurückgegeben, wie in Abschnitt 6.5.2 beschrieben, und der vorläufige NCE für die registrierte Adresse wird entfernt. Andernfalls wird er zu einem registrierten NCE gemacht.

Ein Router DARF den Neighbor Cache NICHT als Ergebnis des Empfangs einer DAC ändern, es sei denn, es gibt einen vorläufigen NCE, der mit der IPv6-Adresse und EUI-64 übereinstimmt.

8.2.6. Wiederherstellung nach Ausfällen

Wenn nach RETRANS_TIMER [RFC4861] keine Antwort von einem 6LBR eingeht, würde der 6LR die DAR bis zu MAX_UNICAST_SOLICIT [RFC4861] Mal an den 6LBR erneut übertragen. Danach SOLLTE der 6LR dem Host mit einem ARO-Status von Null antworten.