3. Protokollübersicht (Protocol Overview)

Diese Neighbor-Discovery-Optimierungen sind sowohl auf mesh-under- als auch auf route-over-Konfigurationen anwendbar. In einer mesh-under-Konfiguration existieren nur 6LoWPAN Border Routers und Hosts; in mesh-under-Topologien gibt es keine 6LoWPAN-Router.

Der wichtigste Teil der Optimierungen ist die weiterentwickelte Host-zu-Router-Interaktion, die schlafende Knoten erlaubt und die Verwendung von Multicast-Neighbor-Discovery-Nachrichten vermeidet, außer wenn ein Host eine anfängliche Menge von Standardroutern findet und wenn diese Bestimmung erneut durchgeführt wird, nachdem diese Routermenge unerreichbar geworden ist.

Das Protokoll stellt außerdem Headerkompression [RFC6282] bereit, indem Headerkompressionsinformationen in einer neuen Option in Router-Advertisement-Nachrichten mitgeführt werden.

Darüber hinaus gibt es separate Mechanismen, die zwischen 6LRs und 6LBRs verwendet werden können, um Multihop Duplicate Address Detection durchzuführen und um Präfix- sowie Kompressionskontextinformationen von den 6LBRs an alle 6LRs zu verteilen, die diese Informationen dann mittels normaler Neighbor-Discovery-Mechanismen an die Hosts weitergeben.

Das Protokoll ist so ausgelegt, dass die Host-zu-Router-Interaktion nicht von der Konfiguration des 6LoWPAN beeinflusst wird; die Host-zu-Router-Interaktion ist in mesh-under- und route-over-Konfigurationen gleich.

3.1. Erweiterungen zu RFC 4861 (Extensions to RFC 4861)

Dieses Dokument spezifiziert die folgenden Optimierungen und Erweiterungen zu IPv6 Neighbor Discovery [RFC4861]:

Vom Host initiierte Auffrischung von Router-Advertisement-Informationen. Dadurch entfällt die Notwendigkeit periodischer oder unaufgeforderter Router Advertisements von Routern an Hosts.
Es wird keine Duplicate Address Detection (DAD) durchgeführt, wenn EUI-64-basierte IPv6-Adressen verwendet werden (da diese Adressen als global eindeutig angenommen werden).
DAD ist optional, wenn DHCPv6 zur Adresszuweisung verwendet wird.
Ein neuer Adressregistrierungsmechanismus, der eine neue Address Registration Option zwischen Hosts und Routern verwendet. Dadurch entfällt die Notwendigkeit, dass Router Multicast Neighbor Solicitations verwenden, um Hosts zu finden, und schlafende Hosts werden unterstützt. Dies ermöglicht außerdem, dass dieselben IPv6-Adresspräfixe über ein route-over-6LoWPAN hinweg verwendet werden. Es stellt die Host-zu-Router-Schnittstelle für Duplicate Address Detection bereit.
Eine neue Router-Advertisement-Option, die 6LoWPAN Context Option, für Kontextinformationen, die von 6LoWPAN header compression verwendet werden.
Ein neuer Mechanismus zur Durchführung von Duplicate Address Detection über ein route-over-6LoWPAN unter Verwendung der neuen Duplicate Address Request- und Duplicate Address Confirmation-Nachrichten.
Neue Mechanismen zur Verteilung von Präfixen und Kontextinformationen über ein route-over-Netz, die eine neue Authoritative Border Router Option verwenden, um das Flooding von Konfigurationsänderungen zu steuern.
Einige neue Standard-Protokollkonstanten werden eingeführt, und einige bestehende Neighbor-Discovery-Protokollkonstanten werden angepasst.

3.2. Adresszuweisung (Address Assignment)

Hosts in einem 6LoWPAN konfigurieren ihre IPv6-Adressen wie in [RFC4861] und [RFC4862] spezifiziert, basierend auf den Informationen, die in Router-Advertisement-Nachrichten empfangen werden. Die Verwendung des M-Flags (managed address configuration) ist in dieser Optimierung jedoch restriktiver als in [RFC4861]. Wenn das M-Flag gesetzt ist, wird angenommen, dass ein Host DHCPv6 verwendet, um alle nicht EUI-64-basierten Adressen zuzuweisen. Wenn das M-Flag nicht gesetzt ist, unterstützen die Knoten im LoWPAN Duplicate Address Detection; somit kann ein Host dann den Adressregistrierungsmechanismus sicher verwenden, um die Eindeutigkeit nicht EUI-64-basierter Adressen zu prüfen.

6LRs MAY dieselben Mechanismen verwenden, um ihre IPv6-Adressen zu konfigurieren.

Die 6LBRs sind für die Verwaltung der dem 6LoWPAN zugewiesenen Präfix(e) verantwortlich, mittels manueller Konfiguration, DHCPv6 Prefix Delegation [RFC3633] oder anderer Mechanismen. In einem isolierten LoWPAN SHOULD ein Unique Local Address (ULA) [RFC4193]-Präfix durch den 6LBR erzeugt werden.

3.3. Host-zu-Router-Interaktion (Host-to-Router Interaction)

Ein Host sendet Router-Solicitation-Nachrichten beim Start sowie dann, wenn die Neighbor Unreachability Detection (NUD) eines seiner Standardrouter fehlschlägt.

Hosts empfangen Router-Advertisement-Nachrichten, die typischerweise die Authoritative Border Router Option (ABRO) enthalten und optional zusätzlich zu den bestehenden Prefix Information Options (PIOs) wie in [RFC4861] beschrieben eine oder mehrere 6LoWPAN Context Options (6COs) enthalten können.

Wenn ein Host eine nicht link-lokale IPv6-Adresse konfiguriert hat, registriert er diese Adresse bei einem oder mehreren seiner Standardrouter, indem er die Address Registration Option (ARO) in einer NS-Nachricht verwendet. Der Host wählt eine Lebensdauer der Registrierung und wiederholt die ARO periodisch (bevor die Lebensdauer abläuft), um die Registrierung aufrechtzuerhalten. Die Lebensdauer sollte so gewählt werden, dass die Registrierung selbst dann aufrechterhalten wird, wenn ein Host schläft. Ebenso sollten mobile Knoten, die ihren Anbindungspunkt häufig wechseln, eine angemessen kurze Lebensdauer verwenden. Siehe Abschnitt 5.5 für Registrierungsdetails und Abschnitt 9 für Protokollkonstanten.

Die Registrierung schlägt fehl, wenn eine ARO mit einem von Null verschiedenen Status an den Host zurückgegeben wird. Ein Grund kann sein, dass der Router feststellt, dass die IPv6-Adresse bereits von einem anderen Host verwendet wird, d. h. von einem Host mit einem anderen EUI-64. Dies kann verwendet werden, um nicht EUI-64-basierte Adressen wie temporäre IPv6-Adressen [RFC4941] oder Adressen zu unterstützen, die auf einer Interface ID basieren, die eine IEEE 802.15.4 16-bit short address ist. Ein Fehlschlag kann auch auftreten, wenn der Neighbor Cache auf diesem Router voll ist.

Die erneute Registrierung einer Adresse kann mit der Neighbor Unreachability Detection (NUD) des Routers kombiniert werden, da beide Unicast Neighbor Solicitation-Nachrichten verwenden. Das macht die Dinge effizient, wenn ein Host aufwacht, um ein Paket zu senden, und sowohl NUD ausführen muss, um zu prüfen, dass der Router weiterhin erreichbar ist, als auch seine Registrierung beim Router auffrischen muss.

Die Antwort auf eine Adressregistrierung ist möglicherweise nicht unmittelbar, da in route-over-Konfigurationen der 6LR Duplicate Address Detection gegenüber dem 6LBR durchführen könnte. Ein Host sendet die Address Registration Option erneut, bis sie durch den Empfang einer Address Registration Option bestätigt wird.

Als Teil der Optimierungen wird die Adressauflösung nicht durch Multicast von Neighbor Solicitation-Nachrichten wie in [RFC4861] durchgeführt. Stattdessen halten die Router Neighbor Cache Entries für alle registrierten IPv6-Adressen. Wenn die Adresse nicht im Neighbor Cache des Routers ist, dann existiert die Adresse entweder nicht, ist einem Host zugeordnet, der an einen anderen Router im 6LoWPAN angebunden ist, oder ist extern zum 6LoWPAN. In einer route-over-Konfiguration wird das Routingprotokoll verwendet, um solche Pakete zum Ziel zu routen.

3.4. Router-zu-Router-Interaktion (Router-to-Router Interaction)

Die neue Router-zu-Router-Interaktion gilt nur für die route-over-Konfiguration, in der 6LRs vorhanden sind. Siehe auch Abschnitt 1.4.

6LRs MUST sich während Systemstart und Präfixkonfiguration wie ein Host verhalten, indem sie Router-Solicitation-Nachrichten senden und ihre IPv6-Adressen autokonfigurieren, anders als Router in [RFC4861].

Wenn Multihop-Präfix- und Kontextverteilung verwendet werden, speichern die 6LRs die ABRO-, 6CO- und Präfixinformationen, die (direkt oder indirekt) von den 6LBRs empfangen wurden, und verteilen diese Informationen erneut in den Router Advertisements, die sie an andere 6LRs senden oder als Antwort auf eine Router Solicitation an Hosts senden. In der ABRO gibt es ein Version-Number-Feld (siehe Abschnitt 4.3), das verwendet wird, um das Flooding aktualisierter Informationen zwischen den 6LRs zu begrenzen.

Ein 6LR kann Duplicate Address Detection gegenüber einem oder mehreren 6LBRs unter Verwendung der neuen Duplicate Address Request (DAR)- und Duplicate Address Confirmation (DAC)-Nachrichten durchführen, die die Informationen aus der Address Registration Option tragen. Die DAR- und DAC-Nachrichten werden zwischen 6LR und 6LBRs weitergeleitet; daher gilt die [RFC4861]-Regel zur Prüfung hop limit=255 nicht für DAR- und DAC-Nachrichten. Diese Multihop-DAD-Nachrichten MUST NOT irgendwelche Neighbor Cache Entries auf den Routern verändern, da wir nicht die Sicherheitsvorteile der hop limit=255-Prüfung haben.

3.5. Neighbor-Cache-Verwaltung (Neighbor Cache Management)

Die Verwendung expliziter Registrierungen mit Lebensdauern sowie der Wunsch, keine Multicast Neighbor Solicitation-Nachrichten für Hosts zu senden, implizieren, dass wir die Neighbor Cache Entries (NCEs) etwas anders verwalten als in [RFC4861]. Dies führt zu drei verschiedenen Typen von NCEs, und die Typen geben an, wie diese Einträge entfernt werden können:

Garbage-collectible (garbage-collectible): Einträge, die den normalen Regeln in [RFC4861] unterliegen, die Garbage Collection bei Speichermangel erlauben.
Registered (registered): Einträge, die eine explizit registrierte Lebensdauer haben und bis zum Ablauf dieser Lebensdauer oder bis sie explizit deregistriert werden, beibehalten werden.
Tentative (tentative): Einträge, die temporär mit kurzer Lebensdauer sind und typischerweise in Registered-Einträge umgewandelt werden.

Beachte, dass der Typ des NCE orthogonal zu den in [RFC4861] spezifizierten Zuständen ist.

Wenn ein Host mit einem Router interagiert, indem er Router Solicitations sendet, führt dies zu einem Tentative NCE. Sobald ein Router erfolgreich erreicht hat, dass sich ein Knoten bei ihm registriert, ist das Ergebnis ein Registered NCE. Wenn Router RAs an Hosts senden und wenn Router RA-Nachrichten empfangen oder Multicast-NS-Nachrichten von anderen Routern empfangen, ist das Ergebnis Garbage-collectible NCEs. Für eine IP-Adresse kann es jeweils nur eine Art von NCE geben.

Neighbor Cache Entries auf Routern können zusätzlich durch ein im 6LoWPAN verwendetes Routingprotokoll hinzugefügt oder gelöscht werden. Das ist nützlich, wenn das Routingprotokoll die Link-Layer-Adressen benachbarter Router transportiert. Abhängig von den Details solcher Routingprotokolle könnten solche NCEs entweder Registered oder Garbage-collectible sein.