5. Host-Verhalten (Host Behavior)

Hosts in einem LoWPAN verwenden die ARO in den von ihnen gesendeten NS-Nachrichten als Möglichkeit, den Neighbor Cache in den Routern zu pflegen, wodurch die Notwendigkeit von multicast NSs zur Adressauflösung entfällt. Anders als in [RFC4861] initiieren die Hosts die Aktualisierung der Informationen, die sie in RAs erhalten, indem sie RSs senden, bevor die Informationen ablaufen. Schließlich, wenn NUD anzeigt, dass einer oder alle Standardrouter unerreichbar geworden sind, verwendet der Host RSs, um eine neue Menge von Standardroutern zu finden.

5.1. Verbotene Aktionen (Forbidden Actions)

Ein Host MUST NOT eine NS-Nachricht multicast senden.

5.2. Schnittstelleninitialisierung (Interface Initialization)

Wenn die Schnittstelle auf einem Host initialisiert wird, folgt sie der Spezifikation in [RFC4861]. Eine Link-Local-Adresse wird basierend auf dem der Schnittstelle zugewiesenen EUI-64-Bezeichner [EUI64] gemäß [RFC4944] oder dem für den Link geeigneten IP-over-foo-Dokument gebildet, und dann sendet der Host RS-Nachrichten wie in [RFC4861] Abschnitt 6.3.7 beschrieben.

Es besteht keine Notwendigkeit, der solicited-node Multicast-Adresse beizutreten, da in dieser Art von Netzwerk niemand NSs multicast sendet. Ein Host MUST der all-nodes Multicast-Adresse beitreten.

5.3. Senden einer Router Solicitation (Sending a Router Solicitation)

Die RS wird wie in [RFC4861] spezifiziert formatiert und an die IPv6 all-routers Multicast-Adresse gesendet (siehe [RFC4861] Abschnitt 6.3.7 für Details). Ein SLLAO MUST enthalten sein, um unicast RAs als Antwort zu ermöglichen. Eine unspecified Quelladresse MUST NOT in RS-Nachrichten verwendet werden.

Wenn die Link-Schicht eine Möglichkeit unterstützt, Pakete an eine Art all-routers anycast Link-Layer-Adresse zu senden, dann MAY dies verwendet werden, um diese Pakete zu einem Router zu transportieren.

Da Hosts nicht von multicast RAs abhängen, um Router zu entdecken, müssen Hosts RSs intelligent retransmittieren, wann immer die Standardrouterliste leer ist, einer ihrer Standardrouter unerreichbar wird oder die Lebensdauer der Präfixe und Kontexte in der vorherigen RA kurz vor dem Ablauf steht. Die RECOMMENDED Wiederholrate besteht darin, zunächst bis zu 3 (MAX_RTR_SOLICITATIONS) RS-Nachrichten zu senden, die durch mindestens 10 Sekunden (RTR_SOLICITATION_INTERVAL) getrennt sind, wie in [RFC4861] spezifiziert, und dann auf langsamere Retransmissions umzuschalten. Nach den initialen Retransmissions SHOULD der Host einen abgeschnittenen binären exponentiellen Backoff (truncated binary exponential backoff) [ETHERNET] des Retransmission-Timers für jede nachfolgende Retransmission durchführen und die Erhöhung des Retransmission-Timers bei 60 Sekunden (MAX_RTR_SOLICITATION_INTERVAL) abschneiden. In allen Fällen werden die RS-Retransmissions beendet, wenn eine RA empfangen wird. Siehe Abschnitt 9 für Protokollkonstanten.

5.4. Verarbeitung einer Router Advertisement (Processing a Router Advertisement)

Die Verarbeitung von RAs erfolgt wie in [RFC4861], mit der Ergänzung der Behandlung der 6CO und des Auslösens der Adressregistrierung, wenn eine neue Adresse konfiguriert wurde. Außerdem MUST der SLLAO in der RA enthalten sein. Anders als in [RFC4861] MAY der Maximalwert des RA-Feldes Router Lifetime bis zu 0xFFFF (ungefähr 18 Stunden) betragen.

Sollte der Host irrtümlich eine PIO mit gesetztem L-(on-link)-Flag empfangen, dann MUST diese PIO ignoriert werden.

5.4.1. Adresskonfiguration (Address Configuration)

Die Adresskonfiguration folgt [RFC4862]. Für eine Adresse, die nicht aus einer EUI-64 abgeleitet ist, bestimmt das M-Flag der RA, wie die Adresse konfiguriert werden kann. Wenn das M-Flag in der RA gesetzt ist, dann MUST DHCPv6 verwendet werden, um die Adresse zuzuweisen. Wenn das M-Flag nicht gesetzt ist, kann die Adresse auf jede andere Weise konfiguriert werden (und die Duplicate Detection wird als Teil des Registrierungsprozesses durchgeführt).

Sobald eine Adresse konfiguriert wurde, wird sie registriert, indem eine NS mit einer ARO an einen oder mehrere Router unicasted wird.

5.4.2. Speichern von Kontexten (Storing Contexts)

Der Host pflegt eine konzeptionelle Datenstruktur für die Kontextinformationen, die er von den Routern erhält. Diese Struktur wird context table genannt. Sie umfasst die CID, das Präfix (aus dem Feld Context Prefix in der 6CO), das Compression-Bit und den Valid Lifetime. Ein context-table-Eintrag, bei dem das Compression-Bit nicht gesetzt ist, wird zur Dekompression beim Empfang von Paketen verwendet, MUST NOT jedoch zur Kompression beim Senden von Paketen verwendet werden.

Wenn eine 6CO in einer RA empfangen wird, wird sie verwendet, um die Informationen in der context table hinzuzufügen oder zu aktualisieren. Wenn das CID-Feld in der 6CO einem bestehenden context-table-Eintrag entspricht, wird dieser Eintrag mit den Informationen aus der 6CO aktualisiert. Wenn das Valid-Lifetime-Feld in der 6CO Null ist, wird der Eintrag sofort gelöscht.

Wenn es keinen passenden Eintrag in der context table gibt und das Valid-Lifetime-Feld ungleich Null ist, wird ein neuer Kontext zur context table hinzugefügt. Die 6CO wird verwendet, um den erstellten Eintrag zu aktualisieren.

Wenn der 6LBR die Kontextinformationen ändert, bemerkt ein Host dies möglicherweise nicht sofort. Im schlimmsten Fall kann ein Host veraltete Kontextinformationen haben. Aus diesem Grund verwenden 6LBRs die Empfehlungen in Abschnitt 7.2, um den Kontext-Lebenszyklus sorgfältig zu verwalten. Knoten sollten vorsichtig sein, Headerkompression in RA-Nachrichten zu verwenden, die 6COs enthalten.

5.4.3. Pflege von Präfix- und Kontextinformationen (Maintaining Prefix and Context Information)

Die Präfixinformationen laufen wie in [RFC4861] spezifiziert ab. Wenn der Valid Lifetime eines context-table-Eintrags abläuft, wird der Eintrag in einen reinen Empfangsmodus (receive-only) versetzt, was dem Empfang einer 6CO für diesen Kontext mit C=0 entspricht. Der Eintrag wird für einen Zeitraum von dem Doppelten der Standard-Router-Lifetime im Empfangsmodus gehalten, danach wird der Eintrag entfernt.

Ein Host sollte die verschiedenen Lifetimes untersuchen, um zu bestimmen, wann er als nächstes den Versand einer RS initiieren sollte, um nach Aktualisierungen der Informationen zu fragen. Die maßgeblichen Lifetimes sind die Standard-Router-Lifetime, die Valid Lifetime in den PIOs und die Valid Lifetime in der 6CO. Der Host SHOULD eine oder mehrere RSs an den Router weit vor dem Ablauf der kürzesten dieser Lifetimes (über alle Präfixe und alle Kontexte) unicasten und dann auf multicast RS-Nachrichten umschalten, wenn es keine Antwort auf die Unicasts gibt. Das Retransmission-Verhalten für die RSs ist in Abschnitt 5.3 spezifiziert.

5.5. Registrierung und Neighbor Unreachability Detection (Registration and Neighbor Unreachability Detection)

Hosts senden unicast NS-Nachrichten, um ihre IPv6-Adressen zu registrieren, und auch, um NUD auszuführen, um zu überprüfen, dass ihre Standardrouter noch erreichbar sind. Die Registrierung wird dadurch durchgeführt, dass der Host eine ARO in die von ihm gesendete NS aufnimmt. Selbst wenn der Host keine Daten zu senden hat, aber erwartet, dass andere versuchen, Pakete an den Host zu senden, muss der Host seine NCEs in den Routern pflegen. Dies geschieht, indem NS-Nachrichten mit einer ARO an den Router weit vor dem Ablauf der Registration Lifetime gesendet werden. NS-Nachrichten werden bis zu MAX_UNICAST_SOLICIT mal retransmittiert, mit einem minimalen Timeout von RETRANS_TIMER, bis der Host eine NA-Nachricht mit einer ARO empfängt.

Hosts, die RA-Nachrichten von mehreren Standardroutern empfangen, SHOULD versuchen, sich bei mehr als einem davon zu registrieren, um die Robustheit des Netzwerks zu erhöhen.

Beachte, dass NUD-Probes durch Reachability-Confirmations aus Transportprotokollen oder Anwendungen wie in [RFC4861] spezifiziert unterdrückt werden können.

Wenn ein Host weiß, dass er einen Router, bei dem er registriert ist, nicht mehr verwenden wird, SHOULD er sich beim Router deregistrieren, indem er eine NS mit einer ARO sendet, die eine Lifetime von 0 enthält. Um den Fall zu behandeln, dass ein Host unfreiwillig die Konnektivität zum Standardrouter verliert, SHOULD der Host eine geeigneterweise niedrige Registration Lifetime verwenden.

5.5.1. Senden einer Neighbor Solicitation (Sending a Neighbor Solicitation)

Der Host löst das Senden von NS-Nachrichten mit einer ARO aus, wenn eine neue Adresse konfiguriert wird, wenn er einen neuen Standardrouter entdeckt, oder weit bevor die Registration Lifetime abläuft. Eine solche NS MUST eine SLLAO enthalten, da der Router die Link-Layer-Adresse des Hosts aufzeichnen muss. Eine unspecified Quelladresse MUST NOT in NS-Nachrichten verwendet werden.

5.5.2. Verarbeitung einer Neighbor Advertisement (Processing a Neighbor Advertisement)

Ein Host behandelt NA-Nachrichten wie in [RFC4861] spezifiziert, mit zusätzlicher Logik in diesem Abschnitt zur Behandlung der ARO.

Zusätzlich zur normalen Validierung einer NA und ihrer Optionen wird die ARO (falls vorhanden) wie folgt verifiziert. Wenn das Length-Feld nicht zwei ist, wird die Option stillschweigend ignoriert. Wenn das EUI-64-Feld nicht der EUI-64 der Schnittstelle entspricht, wird die Option stillschweigend ignoriert.

Wenn das Status-Feld Null ist, war die Adressregistrierung erfolgreich. Der Host speichert die Registration Lifetime aus der ARO, um eine neue NS weit vor Ablauf der Lifetime auszulösen. Wenn das Status-Feld nicht gleich Null ist, ist die Adressregistrierung fehlgeschlagen.

5.5.3. Wiederherstellung nach Fehlern (Recovering from Failures)

Das Verfahren zur Pflege von Reachability-Informationen über einen Nachbarn ist dasselbe wie in [RFC4861] Abschnitt 7.3, mit der Ausnahme, dass keine Adressauflösung durchgeführt wird.

Das Adressregistrierungsverfahren kann aus zwei Gründen fehlschlagen: Es wird keine Antwort auf NSs empfangen (NUD-Fehler), oder es wird eine ARO mit einem Fehler-Status (Status > 0) empfangen. Im Fall eines NUD-Fehlers wird der Eintrag für diesen Router entfernt; daher ist Adressregistrierung nicht länger von Bedeutung. Wenn eine ARO mit einem ungleich Null Status-Feld empfangen wird, zeigt dies an, dass die Registrierung für diese Adresse fehlgeschlagen ist. Ein Fehler-Status von eins zeigt an, dass eine doppelte Adresse erkannt wurde, und es wird das in [RFC4862] Abschnitt 5.4.5 beschriebene Verfahren befolgt. Der Host MUST NOT die Adresse verwenden, die er zu registrieren versucht hat. Wenn der Host gültige Registrierungen bei anderen Routern hat, MUST diese entfernt werden, indem er sich bei jedem mit einer ARO lifetime von Null registriert.

Ein Status-Code von zwei zeigt an, dass der Neighbor Cache dieses Routers voll ist. In diesem Fall SHOULD der Host diesen Router aus seiner Standardrouterliste entfernen und versuchen, sich bei einem anderen Router zu registrieren. Wenn die Standardrouterliste des Hosts leer ist, muss er zur RS-Sendung wie in Abschnitt 5.3 spezifiziert zurückkehren.

Andere Fehlercodes können in zukünftigen Dokumenten definiert werden.

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

Die IP-Adresse des nächsten Hops für ein Ziel wird wie folgt bestimmt. Ziele zum Link-Local-Präfix (fe80::) werden immer auf dem Link an dieses Ziel gesendet. Es wird angenommen, dass Link-Local-Adressen wie in Abschnitt 5.2 aus der EUI-64 gebildet werden und keine Adressauflösung durchgeführt wird. Pakete werden an Link-Local-Ziele gesendet, indem das Verfahren in Anhang A von [RFC4291] umgekehrt wird.

Multicast-Adressen werden als on-link betrachtet und wie in [RFC4944] oder im geeigneten IP-over-foo-Dokument spezifiziert aufgelöst. Beachte, dass [RFC4944] nur definiert, wie eine Multicast-Zieladresse im LoWPAN-Header dargestellt wird. Die Unterstützung für Multicast-Scopes größer als link-local benötigt einen geeigneten Multicast-Routing-Algorithmus.

Alle anderen Präfixe werden als off-link [RFC5889] angenommen. Anycast-Adressen werden immer als off-link betrachtet. Sie werden daher an einen der Router in der Standardrouterliste gesendet.

Ein LoWPAN-Knoten muss nicht mindestens einen Puffer pro Nachbar wie in [RFC4861] spezifiziert vorhalten, da Pakete nie in einer Warteschlange gehalten werden, während auf Adressauflösung gewartet wird.

5.7. Adressauflösung (Address Resolution)

Der Adressregistrierungsmechanismus und der SLLAO in RA-Nachrichten liefern ausreichend a-priori Zustand in Routern und Hosts, um eine IPv6-Adresse in ihre zugehörige Link-Layer-Adresse aufzulösen. Da alle Präfixe außer dem Link-Local-Präfix und Multicast-Adressen stets als off-link angenommen werden, ist multicast-basierte Adressauflösung zwischen Nachbarn nicht erforderlich.

Link-Layer-Adressen für Nachbarn werden in NCEs [RFC4861] gespeichert. Um LoWPAN-Kompression zu erreichen, werden die meisten globalen Adressen unter Verwendung einer Link-Layer-Adresse gebildet. Daher kann ein Host den Speicherverbrauch reduzieren, indem er für diesen Fall optimiert und Link-Layer-Adressinformationen nur speichert, wenn sie sich von der Link-Layer-Adresse unterscheidet, die zur Interface ID der IPv6-Adresse gehört (d. h. sich in mehr als nur dem invertierten on-link/global-Bit unterscheidet).

5.8. Schlafen (Sleeping)

Es ist für batteriebetriebene Hosts in LoWPANs oft vorteilhaft, einen niedrigen Duty Cycle beizubehalten. Die in diesem Dokument beschriebenen Optimierungen ermöglichen Hosts zu schlafen, wie in diesem Abschnitt weiter beschrieben. Router möchten möglicherweise Verkehr cachen, der an einen schlafenden Host gerichtet ist, aber eine solche Funktionalität liegt außerhalb des Geltungsbereichs dieses Dokuments.

5.8.1. Auswahl einer geeigneten Registration Lifetime (Picking an Appropriate Registration Lifetime)

Da alle ND-Nachrichten von den Hosts initiiert werden, erlaubt dies einem Host, zwischen NS/NA-Austauschen zu schlafen oder anderweitig unerreichbar zu sein. Die an NS-Nachrichten angehängte ARO zeigt einem Router an, die NCE für diese Adresse für den Zeitraum im Feld Registration Lifetime gültig zu halten. Ein Host sollte eine Schlafzeit wählen, die zu seinen Energieeigenschaften passt, und eine Registration Lifetime wählen, die größer als die Schlafzeit ist, um sicherzustellen, dass die Registrierung erfolgreich erneuert wird (unter Berücksichtigung von beispielsweise Clock Drift und zusätzlicher Zeit für potenzielle Retransmissions der Re-Registrierung). Eine externe Konfiguration eines Hosts sollte auch die Stabilität des Netzwerks (wie schnell sich die Topologie ändert) berücksichtigen, wenn seine Schlafzeit (und somit Registration Lifetime) gewählt wird. Ein dynamisches Netzwerk erfordert eine kürzere Schlafzeit, damit Router nicht länger als nötig ungültige NCEs für Knoten behalten.

5.8.2. Verhalten beim Aufwachen (Behavior on Wakeup)

Wenn ein Host aus einer Schlafperiode aufwacht, SHOULD er seine aktuellen Adressregistrierungen auffrischen, die vor dem nächsten Aufwachen ablaufen werden. Dies geschieht durch das Senden von NS-Nachrichten mit einer ARO wie in Abschnitt 5.5.1 beschrieben. Der Host muss möglicherweise auch seine Präfix- und Kontextinformationen auffrischen, indem er eine neue unicast RS sendet (die maximale Router Lifetime beträgt etwa 18 Stunden, während die maximale Registration Lifetime etwa 45,5 Tage beträgt). Wenn der Host nach dem Aufwachen (unter Verwendung von NUD) feststellt, dass einige oder alle vorherigen Standardrouter unerreichbar geworden sind, dann sendet der Host multicast RSs, um neue Standardrouter zu entdecken und den Adressregistrierungsprozess neu zu starten.