7. Verhalten des Border-Routers
Ein 6LBR handhabt das Senden von RAs und die Verarbeitung von NSs von Hosts wie oben in Abschnitt 6 beschrieben. Ein 6LBR SOLLTE immer eine ABRO in den von ihm gesendeten RAs enthalten und sich selbst als 6LBR-Adresse auflisten. Dies erfordert, dass der 6LBR die Versionsnummer in einem stabilen Speicher verwaltet und die Versionsnummer erhöht, wenn sich einige Informationen in seinen RAs ändern. Die Informationen, deren Änderung die Version beeinflusst, befinden sich in den PIOs (die Präfixe oder ihre Lebensdauer) und in den 6CO (die Präfixe, CIDs oder Lebensdauer).
Zusätzlich wird ein 6LBR irgendwie mit dem Präfix oder den Präfixen konfiguriert, die dem LoWPAN zugewiesen sind, und kündigt diese in RAs an, wie in [RFC4861]. Im Falle von Route-Over können diese Präfixe unter Verwendung der in Abschnitt 8.1 diskutierten Technik an alle 6LRs verteilt werden. Es kann jedoch Mechanismen außerhalb des Geltungsbereichs dieses Dokuments geben, die als Ersatz für die Präfixverteilung in der Route-Over-Topologie verwendet werden können (siehe Abschnitt 1.4).
Wenn das 6LoWPAN Header-Komprimierung [RFC6282] mit Kontext verwendet, muss der 6LBR die CIDs verwalten und diese in RAs ankündigen, indem er 6COs in seine RAs aufnimmt, damit direkt angeschlossene Hosts über die CIDs informiert werden. Im Folgenden geben wir an, was zu beachten ist, wenn der 6LBR Kontextinformationen hinzufügen, entfernen oder ändern muss. Im Falle von Route-Over werden die Kontextinformationen unter Verwendung der in Abschnitt 8 diskutierten Technik an alle 6LRs verteilt, es sei denn, eine andere Spezifikation bietet einen Ersatz für diese Multi-Hop-Verteilung.
7.1. Präfixbestimmung
Das oder die in einem LoWPAN verwendeten Präfixe können manuell konfiguriert oder mittels DHCPv6-Präfixdelegierung [RFC3633] bezogen werden. Für ein LoWPAN, das dauerhaft oder gelegentlich vom Netzwerk isoliert ist, kann der 6LBR ein ULA-Präfix unter Verwendung von [RFC4193] zuweisen. Das ULA-Präfix sollte in einem stabilen Speicher gespeichert werden, damit dasselbe Präfix nach einem Ausfall des 6LBR verwendet wird. Wenn das LoWPAN mehrere 6LBRs hat, sollten diese mit demselben Satz von Präfixen konfiguriert werden. Der Satz von Präfixen ist in den RA-Nachrichten enthalten, wie in [RFC4861] angegeben.
7.2. Kontextkonfiguration und -verwaltung
Wenn das 6LoWPAN Header-Komprimierung [RFC6282] mit Kontext verwendet, muss der 6LBR mit Kontextinformationen und zugehörigen CIDs konfiguriert werden. Wenn das LoWPAN mehrere 6LBRs hat, MÜSSEN diese mit denselben Kontextinformationen und CIDs konfiguriert werden. Wie in [RFC6282] erwähnt, ist die Aufrechterhaltung der Konsistenz der Kontextinformationen entscheidend, um sicherzustellen, dass Pakete korrekt dekomprimiert werden.
Die in RA-Nachrichten übertragenen Kontextinformationen stammen von 6LBRs und müssen an alle Router und Hosts innerhalb des LoWPAN verteilt werden. RAs enthalten eine 6CO für jeden Kontext.
Für die Verteilung von Kontextinformationen unter Verwendung der 6CO SOLLTE ein strenger Lebenszyklus verwendet werden, um sicherzustellen, dass die Kontextinformationen im gesamten LoWPAN synchron bleiben. Neue Kontextinformationen SOLLTEN mit C=0 in das LoWPAN eingeführt werden, um sicherzustellen, dass sie allen Knoten bekannt sind, die möglicherweise eine Header-Dekomprimierung basierend auf diesen Kontextinformationen durchführen müssen. Erst wenn vernünftigerweise angenommen werden kann, dass diese Informationen erfolgreich verteilt wurden, SOLLTE eine Option mit C=1 gesendet werden, die die tatsächliche Verwendung der Kontextinformationen zur Komprimierung ermöglicht.
Umgekehrt SOLLTEN alte Werte eines Kontexts eine Zeit lang außer Betrieb genommen werden, bevor diesem spezifischen Kontext neue Werte zugewiesen werden, um die Situation zu vermeiden, dass Knoten Pakete senden, die frühere Werte von Kontexten verwenden – was zu Mehrdeutigkeiten beim Empfang eines Pakets führen würde, das einen kürzlich geänderten Kontext verwendet. Das heißt, in Vorbereitung auf eine Änderung von Kontextinformationen SOLLTE deren Verteilung für mindestens MIN_CONTEXT_CHANGE_DELAY mit C=0 fortgesetzt werden. Erst wenn vernünftigerweise angenommen werden kann, dass die Tatsache, dass der Kontext jetzt ungültig ist, erfolgreich verteilt wurde, sollte die CID aus der Verteilung genommen oder mit einem anderen Kontext-Präfix-Feld wiederverwendet werden. Im letzteren Fall SOLLTE die Verteilung des neuen Werts wieder mit C=0 beginnen, wie oben.