Zusammenfassung

  • RFC 9685 erweitert 6LoWPAN Neighbor Discovery um Abonnements für Multicast- und Anycast-Adressen und kann den daraus entstehenden Erreichbarkeitszustand in RPL verteilen.
  • Der neue Non-Storing-Multicastmodus MOP 5 darf nicht in einer laufenden Instanz aktiviert werden; Betreiber müssen eine neue Instanz aufbauen und Knoten migrieren.
  • Ein erfolgreicher Wechsel braucht getrennte Belege für Abonnement, Zustand je Ursprung, Instanzzugehörigkeit, DAO-Ausbreitung, Replikation oder Auswahl, Funkzustellung und Anwendungsempfang.

Der Änderungsantrag sah harmlos aus: MOP von der alten Betriebsart auf 5 setzen, Konfiguration verteilen, Dienst als migriert markieren. Genau dieser Ablauf ist nach RFC 9685 nicht zulässig. Eine laufende RPL-Instanz wird nicht an Ort und Stelle auf MOP 5 aktualisiert. Eine neue Instanz muss entstehen, und die Knoten müssen in sie überführt werden.

Damit wird aus einem vermeintlichen Schalter eine Folge nachweisbarer Übergänge. Welcher Knoten gehört zu welcher Instanz? Welcher 6LoWPAN Router kennt den Listener? Wo wurde der gemeinsame Zielzustand injiziert? Welcher Root replizierte das Paket? Was geschah mit Geräten, die nur den bisherigen Modus beherrschen? Ohne Antworten ist „MOP 5 aktiv“ eine Absichtserklärung, kein Zustellungsbeleg.

Der Unterschied ist für Führungskräfte relevant, weil eine Migration zeitweise mehrere Wahrheiten erzeugt. Legacy-Unicast kann in der bisherigen Instanz verbleiben, während Multicast oder Anycast eine andere Instanz nutzt. Ein Gerät kann korrekt konfiguriert, aber noch nicht in den wirksamen Pfad aufgenommen sein. Ein Abonnement kann akzeptiert werden, obwohl seine Route noch asynchron verbreitet wird. Und ein vorhandener Zielzustand sagt weiterhin nichts darüber aus, ob eine konkrete Anwendung ein Paket empfangen hat.

Das Abonnement bleibt ein eng begrenzter Vorgang

RFC 8505 definiert die Extended Address Registration Option für 6LoWPAN. RFC 9685 verwendet für Multicast- und Anycast-Adressen den Begriff Abonnement: Mehrere Knoten dürfen dieselbe Adresse empfangen, ohne einen Konflikt um eine exklusive Unicast-Adresse auszulösen.

Das P-Feld kennzeichnet Multicast oder Anycast. Das getrennte R-Flag fordert Erreichbarkeitsverhalten an, einschließlich einer möglichen Routeninjektion. Transaction ID, Lebensdauer und Registration Ownership Verifier binden den Vorgang an Ursprung und Reihenfolge. Falls eine Berechtigung zum Lauschen geprüft wird, läuft die Validierung über EDAR und EDAC zum 6LoWPAN Border Router. Der Schutz des ROVR baut auf RFC 8928 auf.

Eine erfolgreiche NA(EARO) belegt deshalb eine Annahmeentscheidung. Sie belegt nicht, dass der Knoten bereits der neuen RPL-Instanz folgt, dass sein DAO-Zustand am Root angekommen ist, dass die richtige Anycast-Instanz ausgewählt oder eine Multicast-Kopie über den letzten Funkhop zugestellt wurde. Ein kryptografisch oder protokollarisch geschützter Ursprung ist außerdem keine geschäftliche Gruppenberechtigung.

Der Annahmebeleg sollte Teilnehmer, Adresse, P, R, TID, Lebensdauer, ROVR, Linkidentität, EDAR/EDAC-Ergebnis, NA-Status und den antwortenden Router enthalten. Ein zusammengesetztes Feld „migriert und erreichbar“ beseitigt genau die Grenzen, die eine Störung später erklären sollen.

Eine neue Instanz ist ein neuer Zustandsraum

Eine RPL-Instanz ist nicht bloß eine Beschriftung auf bestehenden Tabellen. Sie bestimmt den Kontext, in dem Knoten Ziele ankündigen und Pfade bilden. Der MOP legt fest, welche Rolle Zwischenrouter und Root bei der Zustandsführung spielen. Deshalb lässt sich der Wechsel zu MOP 5 nicht als kompatible In-place-Änderung behandeln.

Die Migration muss mindestens die neue Instanz, den Root, die teilnehmenden Router, die Zuordnung der Blätter, die Unterstützungsdichte und das Verhalten nicht migrierter Geräte nachweisen. In einem Brownfield können parallele Instanzen nötig sein. Das beansprucht knappen Zustand und kann dazu führen, dass ein Knoten die alte Unicast-Funktion weiterhin erfüllt, aber noch keinen wirksamen Multicastpfad in der neuen Instanz besitzt.

Eine Capability-Anzeige ist dafür nur ein Eingangsfakt. Jeder Listener muss einen geeigneten 6LR erreichen. Im Storing-Modus braucht die Topologie zudem genügend unterstützende Router, um einen DODAG bis zum Root zu bilden. Eine Einkaufsliste kompatibler Geräte oder ein globaler Prozentwert beweist weder die lokale Abdeckung noch den Pfad zu einem bestimmten Zeitpunkt.

Die Abnahme sollte daher pro Listener und nicht nur pro Gerätemodell erfolgen: aktuelle Instanz, Elternbeziehung, unterstützter MOP, zuständiger 6LR, Zeitpunkt des letzten Zustandsaufbaus und beobachtbarer Weg zum Root. Erst diese Zuordnung macht aus „Hardware kann es“ eine überprüfbare Deploymentaussage.

Zusammenführung verbirgt die Herkunft

RFC 9685 verlangt Zustand je abonnierender Partei oder Ursprung, erlaubt aber, mehrere Abonnements derselben Adresse zu einem einzigen Routenangebot zusammenzuführen. RPL muss dadurch nicht für jedes Blatt ein separates Ziel veröffentlichen. Für die Skalierung ist das nützlich; für eine Migration ist es gefährlich, wenn die Einzelzustände nicht erhalten bleiben.

Mehrere Ursprünge können unterschiedliche Restlaufzeiten besitzen. Die Route kann sich an der längsten aktiven Lebensdauer orientieren. Ein bereits migrierter Listener kann den gemeinsamen Zielzustand erhalten, während ein anderer noch in der alten Instanz hängt oder ausläuft. Die sichtbare Route sagt dann nicht, welcher Ursprung tatsächlich durch die neue Instanz erreicht wird.

Auch der Zeitpunkt ist getrennt. Registrierung und Routeninjektion sind asynchron. Der 6LR kann das Abonnement annehmen, bevor die Zielinformation in der neuen Instanz sichtbar ist. Das ist kein Widerspruch, sondern eine messbare Übergangsphase. Wer nur den Endzustand prüft, sieht weder die Dauer noch die Lücke, in der Pakete verloren gehen konnten.

Für jede Adresse braucht die Migrationsakte deshalb die Ursprungsregistrierungen, ihre Instanzen, Lebensdauern und Sequenzen, die zusammengeführte Menge, die wirksame längste Laufzeit sowie Zeitpunkte für Injektion, Propagation und Rückzug. Ein einzelner Routen-Snapshot kann diese Geschichte nicht rekonstruieren.

Storing und Non-Storing verlagern die Beweispunkte

Im Storing-Modus von RPL wandert DAO-Zustand über bevorzugte Eltern. Für Multicast entsteht ein Baum; Router senden individuelle Unicast-MAC-Frames über dessen Zweige weiter, außer zurück zum eingehenden Nachbarn. Der Zustellungsnachweis liegt damit auch bei den Zwischenroutern, die den Baumzustand halten.

Im neuen Non-Storing-Multicastmodus repliziert der Root die eingehende Nachricht. Die DAO meldet Multicast-Adressen als Ziele, und der Root kapselt Kopien zu den transitierenden 6LRs. Dafür nutzt er die Source-Routing-Mechanik im Umfeld von RFC 9008. Die neue Instanz verlagert also Zustand und Verantwortung; sie macht den Weg nicht beweisfrei.

Bei Anycast wird nicht repliziert. Mehrere Kinder oder RPL-Knoten können dieselbe Adresse anbieten, doch ein bestimmtes Paket wird nur zu einem Kandidaten geleitet. Während einer Migration kann der Dienst antworten, obwohl stets der bereits migrierte Kandidat gewählt wird und ein anderer ungetestet bleibt. Die Prüfung muss Auswahlregel, gewählten Knoten, Pfad und Ergebnis getrennt festhalten.

RFC 6553 beschreibt RPL-Optionen; RFC 9010 verbindet 6LoWPAN-Registrierung und RPL. Beide liefern Bausteine des Kontrollpfads, keinen Anwendungsbeleg. Ebenso dürfen MLDv2 aus RFC 3810 oder MPL aus RFC 7731 nicht als ersatzweise Nachweise für eine andere Zustandsmaschine verwendet werden.

Ein vollständiger Kontrollpfad endet noch nicht bei der Anwendung

Niedrigenergieverbindungen setzen eine weitere Grenze. Direct MAC Broadcast kann unzuverlässig sein; asynchroner Broadcast kann einen schlafenden Listener zum Wachbleiben zwingen. RFC 9685 sieht deshalb nach Möglichkeit individuelle Unicast-MAC-Frames vom 6LR zu den abonnierten Blättern vor.

Eine installierte Route kann dennoch an einem schlafenden Empfänger enden. Ein Link-Acknowledgment kann vorliegen, während eine höhere Schicht verwirft. Eine Anwendung kann das Datagramm lesen, ohne die beobachtete Geschäftshandlung auszuführen. Keine Instanzmigration hebt diese Unterscheidungen auf.

Der Nachweis muss nach dem Kontrollpfad weitergehen: Multicast-Replikationsmenge oder Anycast-Auswahl, nächster Hop, Frame-Sendung, verfügbare Linkbestätigung, IP-Empfang, Anwendungsquittung und Dienstergebnis. Nur so lässt sich sagen, ob ein Migrationsfehler, eine Zustandslücke, der letzte Hop oder die Anwendung verantwortlich war.

Auch Neustarts gehören in diese Akte. Nicht persistierte Registrierungen können verloren gehen. Ein Router, der Zustand verpasst haben könnte, soll eine asynchrone Auffrischung anfordern. Geschieht das nicht, kann die Wiederherstellung bis zur periodischen Erneuerung warten. Eine zuvor erfolgreiche Abnahme bleibt historisch korrekt, während die gegenwärtige Erreichbarkeit falsch ist.

Scope begrenzt Reichweite, nicht Beweispflicht

RFC 7346 liefert die IPv6-Multicast-Scopes. RFC 9685 ordnet Realm-Local einem RPL-DODAG zu und nutzt Admin-Local, wenn Verkehr eine Föderation von RPL-Instanzen überspannt. Die richtige Scope-Wahl verhindert falsche Reichweite; sie beweist nicht, dass alle Knoten in der vorgesehenen Reichweite migriert sind.

Hier wird die Idee einer minimalen Anfangsspezifikation praktisch: Der gemeinsame Standard schafft Interoperabilität, ohne jede lokale Einführungsentscheidung zu übernehmen. Realitätsschichten verhindern, dass Konfiguration, Abonnement, Route und Empfang zu einem Verwaltungsstatus verschmelzen. Die Priorität laufenden Codes verlangt am Ende die Beobachtung des Systems, das das Paket tatsächlich weiterleitete.

RFC 9685 gibt RPL-unwissenden Blättern Multicast- und Anycast-Dienst, ohne ihnen RPL-Injektionsrechte zu geben. Diese Begrenzung ist ein Vorbild für die Berichterstattung. Die neue Instanz belegt den Migrationskontext. Neighbor Discovery belegt die Annahme. RPL belegt die Verteilung. Der Datenpfad und die Anwendung belegen die Zustellung. MOP 5 ist erst dann erfolgreich, wenn diese getrennten Aussagen zusammenpassen.

Quellen