Zusammenfassung

  • draft-ietf-snac-simple-12 automatisiert die IPv6-Anbindung eines Stub-Netzes, trennt dabei aber Adressierbarkeit, Erreichbarkeit und Auffindbarkeit.
  • Bei Neustart oder Übernahme kann ein neues Präfix neben noch gültigen alten Adressen und Routen stehen. Eine frische RA beweist keine Anwendungskontinuität.
  • Ein begrenzter Übergangsbeleg muss Auslöser, Zustand, Lebensdauern, installierte Route, Discovery und die Transaktion mit tatsächlich gewählter Adresse bewahren.

Die Zustandsmaschine endet vor der Nutzerhandlung

Ein SNAC-Router verbindet ein eingeschränktes IPv6-Stub-Netz mit einem benachbarten Ethernet- oder WLAN-Link. Die Revision 12 nutzt vorhandene Bausteine, statt beide Medien zu einer künstlichen Layer-2-Domäne zu machen.

Der Entwurf unterscheidet Adressierbarkeit, Erreichbarkeit und Discovery. Ein Host kann eine Adresse besitzen, während der Rückweg fehlt. Ein Dienst kann per mDNS erscheinen, obwohl kein Host die Route zum OSNR-Präfix installiert hat. Ein vorhandener Weg kann mit einer alten Quelladresse scheitern.

Eignung braucht Frische und Nachbarschaft

Nach Router Discovery gemäß RFC 4861 führt ein geeignetes On-Link-Präfix zu STATE-SUITABLE; andernfalls beginnt STATE-BEGIN-ADVERTISING.

STALE_RA_TIME beträgt standardmäßig zehn Minuten. Eine ältere RA stützt die Eignung nicht mehr. Zusätzlich überwacht der SNAC-Router die Erreichbarkeit des Werbers; nach höchstens sechzig Sekunden geeigneter ReachableTime wird aktiv geprüft.

Ein Nachbar kann noch antworten, aber keine RAs mehr senden. Eine RA kann frisch sein, während der Router danach ausfällt. Deshalb darf das Präfix nicht die Betriebsfähigkeit seiner Quelle vertreten.

Deprecation ist absichtliche Koexistenz

Ein selbst bereitgestelltes Präfix erhält standardmäßig dreißig Minuten Preferred und Valid Lifetime. Taucht eine bessere Alternative auf, setzt STATE-DEPRECATING die bevorzugte Zeit auf null und reduziert die gültige. Verschwindet die Alternative, kann der Router sein eigenes Präfix wieder aktiv anbieten.

Diese Rückkehrmöglichkeit schützt Verfügbarkeit. Sie synchronisiert aber keine Hosts. Verschiedene Empfangszeiten, verlorene Multicasts und bestehende Sessions erzeugen verschiedene lokale Wahrheiten. Der Routerzustand kennt die gewählte Hostadresse nicht.

RFC 8978 beschreibt Flash Renumbering. Seine allgemeinen SLAAC-Werte von sieben und dreißig Tagen sind nicht die dreißig Minuten des SNAC-Präfixes. Beide Fälle zeigen jedoch: verbleibende Gültigkeit ist kein Nachweis verbleibender Nutzbarkeit.

Der Rückkehrer trifft auf sein früheres Präfix

Router A kann ausfallen, nachdem er ein On-Link-Präfix angeboten hat. Router B übernimmt mit einem anderen. Nach seiner Rückkehr sieht A das geeignete Präfix von B und nimmt das alte nicht wieder auf.

Hosts können die alten Adressen behalten. A empfängt Pakete dafür, betrachtet das Präfix aber nicht mehr als On-Link und leitet sie zum Default Router oder verwirft sie. Der Entwurf nennt zeitweiligen Verlust der IoT-Steuerung und fehlgeschlagene Automationen.

Nicht jeder Neustart renummeriert. Selbst erzeugte OSNR-Präfixe sollen persistent sein; DHCPv6-PD liefert häufig dasselbe Präfix. Wiederholte Wechsel weisen eher auf verlorene Persistenz, lange Abwesenheit, instabile AIL-Anbindung, kurze Leases oder Mesh-Partitionen hin.

Ein gemeinsames /64, etwa aus der Thread Extended PAN ID, hilft. Die Kontinuität bleibt daran gebunden, dass nicht alle Router desselben Stub-Netzes gleichzeitig neu starten.

OSNR hat eine zweite Übergabe

OSNR kann aus DHCPv6-PD nach RFC 9915 oder ULA nach RFC 4193 stammen. Fällt der einzige Anbieter aus, können andere Router den alten Weg weiter annoncieren. Wie sie dasselbe Präfix koordinieren, bleibt außerhalb des Entwurfs.

Ein neuer OSNR kann erscheinen, während alte RIOs bis zum Ablauf weiterlaufen. Das schützt laufende Kommunikation, beweist aber weder die Adresswahl einer neuen Session noch das richtige Ziel nach einer Partition.

Discovery kann den Ausfall verdecken

RA Guard kann SNAC-RAs blockieren und mDNS unverändert lassen. Der Dienst ist sichtbar, aber ohne RIO nach RFC 4191 fehlt dem Infrastrukturhost die Route. NAT64 kann einzelne ausgehende Verbindungen weiter ermöglichen.

Deshalb müssen Routerlog, Hostroute und Anwendungsergebnis verglichen werden. RFC 6762 und RFC 6763 belegen Discovery, nicht Forwarding.

Den Zwischenzustand als Beleg halten

Revision 12 empfiehlt Zeitstempel für Renummerierung, Deprecation, Invalidierung, Wechsel des anbietenden Routers sowie Verlust und Rückkehr der Default Route. Ergänzt werden sollten Boot-Identität, Präfixrolle, alter und neuer Zustand, RA-Quelle und Alter, Nachbarprüfung, Lebensdauern, Deprecation-Beginn, RIO, tatsächlich installierte Hostroute, Discovery und Anwendungstest mit ausgewählter Adresse.

Das gemeinsame Format ist kein Zentralregister. Aufbewahrung und Reparatur bleiben lokal. Lu Hengs Minimum Initial Specification schafft Vergleichbarkeit, nicht neue Fernsteuerung. Reality Layers hält Nachricht, Modell, Betriebsbedingung und Ereignis getrennt.

Quellen

  1. SNAC Revision 12
  2. Historie
  3. Revision 12 HTML
  4. Revision 12 Text
  5. Offizieller Diff 11–12
  6. RFC 4861
  7. RFC 4191
  8. RFC 4193
  9. RFC 8978
  10. RFC 6762
  11. RFC 6763
  12. RFC 7084
  13. RFC 6146
  14. RFC 7050
  15. RFC 9915
  16. Lu Heng — Minimum Initial Specification
  17. Lu Heng — On Reality Layers
  18. Lu Heng — Running Code Primary