6. Router-Verhalten für 6LRs und 6LBRs (Router Behavior for 6LRs and 6LBRs)

6. Router-Verhalten für 6LR und 6LBR (Router Behavior for 6LRs and 6LBRs)

Sowohl 6LRs als auch 6LBRs pflegen den Neighbor Cache [RFC4861] basierend auf den AROs, die sie in NA-Nachrichten von Hosts erhalten, ND-Paketen von anderen Nodes und, potenziell, einem Routingprotokoll, das im 6LoWPAN verwendet wird, wie in Abschnitt 3.5 beschrieben.

Router SHOULD NOT Registered NCEs (siehe Abschnitt 3.4) per Garbage Collection entfernen, da sie diese bis zum Ablauf der Registration Lifetime behalten müssen. Ebenso gilt: Wenn NUD auf dem Router bestimmt, dass der Host UNREACHABLE ist (basierend auf der Logik in [RFC4861]), SHOULD NOT die NCE gelöscht werden, sondern vielmehr bis zum Ablauf der Registration Lifetime erhalten bleiben. Ein erneuertes ARO sollte den Cache-Eintrag als STALE markieren. Somit verhält sich der Neighbor Cache bei 6LoWPAN-Routern nicht wie ein Cache. Stattdessen verhält er sich wie ein Register aller Host-Adressen, die am Router angeschlossen sind.

Router MAY die Default Router Preference (Prf)-Erweiterung [RFC4191] implementieren und damit dem Host anzeigen, ob der Router ein 6LBR oder ein 6LR ist. Wenn dies implementiert ist, dann MUST 6LRs ohne Route zu einem Border Router Prf auf (11) für niedrige Präferenz setzen, andere 6LRs MUST Prf auf (00) für normale Präferenz setzen, und 6LBRs MUST Prf auf (01) für hohe Präferenz setzen.

6.1. Verbotene Aktionen (Forbidden Actions)

Auch wenn ein Router in einer route-over Topologie sowohl einen Host als auch ein anderes Ziel erreichen kann, kann er aufgrund der Funkausbreitung im Allgemeinen nicht wissen, ob der Host das andere Ziel direkt erreichen kann. Daher kann er nicht annehmen, dass Redirect tatsächlich von einem Host zu einem anderen funktioniert. Daher SHOULD NOT er Redirect-Nachrichten senden. Die einzige potenzielle Ausnahme zu diesem "SHOULD NOT" ist, wenn Deployment/Implementierung eine Möglichkeit hat zu wissen, wie der Host das beabsichtigte Ziel erreichen kann. Daher ist es RECOMMENDED, dass die Implementierung standardmäßig keine Redirect-Nachrichten sendet, aber konfigurierbar ist, wenn das Deployment dies erfordert. Im Gegensatz dazu gelten für mesh-under Topologien die gleichen Überlegungen zu Redirects wie in [RFC4861].

Ein Router MUST NOT das L (on-link)-Flag in den PIOs setzen, da dies Hosts dazu veranlassen könnte, multicast NSs zu senden.

6.2. Schnittstelleninitialisierung (Interface Initialization)

Das Initialisierungsverhalten der 6LBR-Router-Schnittstelle ist dasselbe wie in [RFC4861]. In einem dynamischen Konfigurationsszenario (siehe Abschnitt 8.1), startet jedoch ein 6LR als Nicht-Router und wartet, bis er zunächst die Advertisement zum Konfigurieren seiner eigenen Schnittstellenadresse erhält, bevor er seine Schnittstellen zu advertiseenden Schnittstellen macht und zum Router wird.

6.3. Verarbeitung einer Router Solicitation (Processing a Router Solicitation)

Ein Router verarbeitet RS-Nachrichten wie in [RFC4861] spezifiziert. Die Unterschiede betreffen die Einbeziehung von ABROs in die RA-Nachrichten und die ausschließliche Verwendung von unicast RAs. Wenn ein 6LR ein ABRO von einem 6LBR erhalten hat, dann wird er diese Option unverändert in die RA-Nachrichten aufnehmen, die er sendet. Und wenn der 6LR RAs — ob mit denselben Präfix- und Kontextinformationen oder unterschiedlichen — von einem anderen 6LBR erhalten hat, dann muss er diese Präfixe und Kontextinformationen getrennt halten, sodass die RAs, die der 6LR sendet, die Zuordnung zwischen ABRO und Präfix-/Kontextinformationen beibehalten. Der Router kann erkennen, welcher 6LBR die Präfix- und Kontextinformationen ursprünglich erzeugt hat, anhand des 6LBR Address-Felds im ABRO. Wenn ein Router Informationen hat, die an mehrere ABROs gebunden sind, führt ein einzelnes RS zu mehreren RAs, die jeweils ein anderes ABRO enthalten.

Wenn die einem 6LBR zugeordnete ABRO Valid Lifetime abläuft, MUST alle Informationen, die sich auf diesen 6LBR beziehen, entfernt werden. Als Implementierungshinweis wird empfohlen, dass RAs ausreichend häufiger als die ABRO Valid Lifetime gesendet werden, damit das Verpassen einer RA nicht dazu führt, dass alle Informationen zu einem 6LBR entfernt werden.

Ein RS kann von einem Host empfangen werden, der seine Adresse noch nicht beim Router registriert hat. Daher MUST NOT der Router eine bestehende NCE auf Grundlage des SLLAO aus dem RS ändern. Ein Router MAY jedoch eine Tentative NCE auf Grundlage des SLLAO erstellen. Eine solche Tentative NCE SHOULD nach TENTATIVE_NCE_LIFETIME Sekunden ablaufen, sofern nicht eine Registrierung sie in eine Registered NCE umwandelt.

Ein 6LR oder 6LBR MUST ein SLLAO in die RAs aufnehmen, die er sendet; dies ist erforderlich, damit die Hosts die Link-Layer-Adresse des Routers kennen. Anders als in [RFC4861] MAY der Maximalwert des RA Router Lifetime-Felds bis zu 0xFFFF (ungefähr 18 Stunden) betragen.

Anders als [RFC4861], das multicast RAs nahelegt, verbessert diese Spezifikation den Austausch dadurch, dass RAs in Antwort auf RSs immer unicasted werden. Das ist möglich, da das RS immer ein SLLAO enthält, das vom Router verwendet wird, um das RA zu unicasten.

6.4. Periodische Router Advertisements (Periodic Router Advertisements)

Ein Router muss keine periodischen RA-Nachrichten senden, da die Hosts aktualisierte Informationen anfordern, indem sie RSs senden, bevor die Lifetimes ablaufen.

Wenn Router jedoch RAs verwenden, um Präfix- und/oder Kontextinformationen über eine route-over Topologie zu verteilen, kann dies periodische RA-Nachrichten erfordern. Solche RAs werden unter Verwendung der konfigurierbaren MinRtrAdvInterval und MaxRtrAdvInterval gemäß [RFC4861] gesendet.

6.5. Verarbeitung einer Neighbor Solicitation (Processing a Neighbor Solicitation)

Ein Router behandelt NS-Nachrichten wie in [RFC4861] spezifiziert, mit zusätzlicher Logik, die in diesem Abschnitt für die Behandlung der ARO beschrieben ist.

Zusätzlich zur normalen Validierung eines NS und seiner Optionen wird die ARO (falls vorhanden) wie folgt verifiziert. Wenn das Length-Feld nicht zwei ist oder wenn das Status-Feld nicht null ist, wird der NS stillschweigend ignoriert.

Wenn die Quelladresse des NS die unspecified Adresse ist oder wenn kein SLLAO enthalten ist, wird jede enthaltene ARO ignoriert, das heißt, der NS wird so verarbeitet, als enthielte er keine ARO.

6.5.1. Prüfung auf Duplikate (Checking for Duplicates)

Wenn der NS eine gültige ARO enthält, dann inspiziert der Router seinen Neighbor Cache auf der ankommenden Schnittstelle, um zu sehen, ob es ein Duplikat ist. Es ist kein Duplikat, wenn (1) es keine NCE für die IPv6-Quelladresse des NS gibt oder (2) es eine solche NCE gibt und die EUI-64 gleich ist. Andernfalls ist es eine Duplikatadresse. Beachten Sie, dass bei Verwendung von multihop DAD (Abschnitt 8.2) die Prüfungen geringfügig anders sind, um Tentative NCEs zu berücksichtigen. Im Duplikatfall antwortet der Router mit einer unicast NA-Nachricht mit dem ARO Status-Feld auf eins gesetzt (um anzuzeigen, dass die Adresse ein Duplikat ist), wie in Abschnitt 6.5.2 beschrieben. In diesem Fall erfolgt keine Änderung am Neighbor Cache.

6.5.2. Rückgabe von Adressregistrierungsfehlern (Returning Address Registration Errors)

Adressregistrierungsfehler werden wegen eines möglichen Risikos einer L2-Adresskollision nicht an die Quelladresse des NS zurückgesendet. Stattdessen wird die NA an die link-lokale IPv6-Adresse gesendet, deren Interface ID-Teil aus dem EUI-64-Feld der ARO gemäß [RFC4944] abgeleitet ist. Insbesondere bedeutet dies, dass das universal/local Bit invertiert werden muss. Die NA wird mit einer Kopie der ARO aus dem NS formatiert, jedoch mit dem Status-Feld so gesetzt, dass es den angemessenen Fehler anzeigt.

Der Fehler wird an die link-lokale Adresse mit der aus der EUI-64 abgeleiteten Interface ID gesendet. Somit ist, wenn die ARO von und für eine Short Address war, die L2-Zieladresse für die NA mit dem ARO-Fehler die 64-Bit-Unique-Address.

6.5.3. Aktualisierung des Neighbor Cache (Updating the Neighbor Cache)

Wenn die ARO nicht dazu führte, dass wie oben ein Duplikat erkannt wurde, dann erstellt (falls nicht vorhanden) oder aktualisiert (ansonsten) der Router, wenn die Registration Lifetime ungleich null ist, eine NCE für die IPv6-Quelladresse des NS. Wenn der Neighbor Cache voll ist und ein neuer Eintrag erstellt werden muss, antwortet der Router mit einer unicast NA mit dem ARO Status-Feld auf zwei gesetzt (um anzuzeigen, dass der Neighbor Cache des Routers voll ist) wie in Abschnitt 6.5.2 beschrieben.

Die Registration Lifetime und die EUI-64 werden in der NCE aufgezeichnet. Anschließend wird als Antwort auf den NS eine unicast NA gesendet. Diese NA SHOULD eine Kopie der ARO enthalten, wobei das Status-Feld auf null gesetzt ist. Ein TLLAO (Target Link-Layer Address Option) [RFC4861] ist in der NA nicht erforderlich, da der Host die Link-Layer-Adresse des Routers bereits aus den RAs kennt.

Wenn die ARO eine Registration Lifetime von null enthält, dann MUST jede bestehende NCE für die IPv6-Quelladresse des NS gelöscht werden und eine NA wie oben gesendet werden.

Wenn die Registration Lifetime in einer NCE abläuft, dann MUST der Router den Cache-Eintrag löschen.

Das Hinzufügen und Entfernen von Registered NCEs würde zur Benachrichtigung des Routingprotokolls führen.

Hinweis: Wenn substitutable multihop DAD (Abschnitt 8.2) verwendet wird, dann ist die Aktualisierung des Neighbor Cache aufgrund von Tentative NCEs geringfügig anders.

6.5.4. Next-Hop-Bestimmung (Next-Hop Determination)

Um ein Paket zuzustellen, das für einen bei einem Router registrierten 6LN bestimmt ist, ist die Next-Hop-Bestimmung für Router leicht anders als für Hosts (siehe Abschnitt 5.6). Die Routingtabelle wird geprüft, um die Next-Hop-IP-Adresse zu bestimmen. Eine Registered NCE bestimmt, ob die Next-Hop-IP-Adresse on-link ist. Es ist die Verantwortung des Routingprotokolls des Routers, on-link Informationen über seine registrierten Nachbarn zu pflegen. Tentative NCEs MUST NOT zur Bestimmung des on-link Status registrierter Nodes verwendet werden.

6.5.5. Adressauflösung zwischen Routern (Address Resolution between Routers)

Es muss irgendwo einen Mechanismus geben, damit Router die Link-Layer-Adressen der jeweils anderen entdecken können. Wenn das zwischen den Routern verwendete Routingprotokoll dies bereitstellt, dann besteht keine Notwendigkeit, dass die Router die ARO untereinander verwenden. Andernfalls SHOULD die Router die ARO verwenden. Wenn Router die ARO verwenden, um sich gegenseitig zu registrieren, und multihop DAD (Abschnitt 8.2) in Verwendung ist, dann muss darauf geachtet werden, dass es nicht zu einer Flut von ARO-tragenden Nachrichten zum 6LBR kommt, während jeder Router eine ARO von seinen benachbarten Routern hört. Die Details für dieses Szenario liegen außerhalb des Umfangs dieses Dokuments.

Router MAY auch multicast NSs wie in [RFC4861] verwenden, um die Link-Layer-Adressen der jeweils anderen aufzulösen. Somit MAY Router multicast NSs für andere Router senden, zum Beispiel als Ergebnis des Empfangs eines Routingprotokoll-Updates. Router MUST auf multicast NSs antworten. Das impliziert, dass Router MUST den solicited-node Multicast-Adressen wie in [RFC4861] beitreten.