Zusammenfassung

  • L2-LinkConnect.confirm(Ack) bedeutet in RFC 5184, dass die angeforderte Link-Operation beginnen kann; erst ein späteres, technologiespezifisches L2-LinkUp.indication meldet ihren Link-Zustand.
  • Auch LinkUp belegt weder Bridge-Forwarding noch IP-Konfiguration oder Ende-zu-Ende-Verkehr. Ein belastbarer Handover-Beleg muss diese Grenzen einzeln erhalten.

Die Netzwerkkarte meldete Träger. Das Orchestrierungssystem setzte den Anschluss auf „up“ und erklärte den Umzug für beendet. Doch die Bridge befand sich noch nicht im Forwarding-Zustand. Kein Paket erreichte das andere Ende der Broadcast-Domain.

Die Meldung war im Geltungsbereich des Geräts richtig. Falsch war die Behauptung, die man daraus gebaut hatte. RFC 5184 ist gerade deshalb nützlich, weil ihre vier Primitive-Klassen den Zeitpunkt und die Reichweite einer Aussage sichtbar machen.

Eine Bestätigung ist kein vorweggenommenes Ereignis

RFC 5184 ist ein Experimental-Dokument des MobOpts Research Group-Konsenses, kein IETF Internet Standard. Es definiert neun Layer-2-Abstraktionen, mit denen Layer 3 aktuelle Informationen abfragt, asynchrone Ereignisse abonniert und Link-Aktionen anfordert.

Request fragt nach Information oder Dienst. Confirm beantwortet diesen Request. Indication meldet später ein Ereignis. Response kann dessen Empfang bestätigen. Typ 1 liefert über Request und Confirm den aktuellen LinkStatus oder eine PoAList. Typ 2 registriert Ereignisse wie PoAFound, PoALost, LinkUp, LinkDown und LinkStatusChanged. Typ 3 steuert LinkConnect und LinkDisconnect.

Bei Typ 3 kommt Ack oder Nack sofort im Confirm zurück. Nach einem Ack auf L2-LinkConnect beginnt die Operation. Auch nach dem Disconnect-Ack beginnt der Abbau erst. Wer Ack als Fertigstellung speichert, zieht ein späteres Ereignis zeitlich vor und verdeckt jeden Zustand dazwischen.

Das Ablaufbeispiel der RFC lässt keinen Zweifel: Layer 3 sendet LinkConnect Request; nach Confirm startet Layer 2 seinen Handover; nach Abschluss meldet Layer 2 LinkUp; dann vollzieht Layer 3 seinen Handover-Schritt. Command acceptance, Link completion und IP outcome sind verschiedene Belege.

LinkUp gehört immer zu einer konkreten Link-Technik

RFC 5184 sagt, dass die Bedeutung von „connected“ vom Link-Typ abhängt. Im IEEE-802.11-Infrastrukturbeispiel wird LinkUp ausgegeben, wenn die Assoziation mit einem Access Point hergestellt ist. Das ist ein sinnvoller, aber begrenzter Zustand.

RFC 4907 warnt davor, aus LinkUp symmetrische Bedingungen, geringe Verluste, rechtzeitige Meldung oder fertige IP-Konfiguration abzuleiten. Eine Anwendung soll auf ein Ereignis der Internet-Schicht warten, statt die Adresse aus der Link-Meldung zu erraten. Die RFC dokumentiert sogar einen Fall, in dem LinkUp vor abgeschlossener Link-Authentisierung gemeldet wurde und wiederholte DHCP-Fehler begünstigte.

RFC 4957 macht die Ethernet-Grenze konkret. Physische Link-Anzeigen versichern nicht, dass Pakete über eine Bridge-Domain empfangen werden können. Nach Erkennen des Trägers kann Spanning Tree noch verzögern, während dem Host ein explizites Forwarding-Signal fehlt. Ein echtes „carrier up“ ist also nicht automatisch ein unwahres Signal; es ist nur kein Beleg für die breitere Behauptung „Pfad funktioniert“.

Selbst Namen und Kandidaten bestimmen nicht die IP-Folge

L2-PoAList und L2-PoAFound zeigen mögliche Anschlusspunkte. Condition verdichtet verfügbare Bandbreite und Link-Qualität in EXCELLENT, GOOD, FAIR, BAD oder NONE. Der Algorithmus hängt von Hardware und Software ab; die Werte verschiedener Geräte sind unabhängig und können eine fehlerhafte oder nicht optimale Wahl hervorbringen.

Auch BSSID und SSID bestimmen laut RFC 4957 nicht deterministisch, ob eine IP-Neukonfiguration nötig ist. Gleich klingende Namen können verschiedene Pfade verbergen, verschiedene Link-Bezeichner können zur selben IP-Konfiguration führen. Ein Controller muss daher den konkreten Zusammenhang aus Interface, PoA, Authentisierung, Router, Adresse und Weiterleitung prüfen.

Der Zeitpunkt einer Indication ist in RFC 5184 nicht spezifiziert. Scan- und Implementierungsverfahren bestimmen ihn. Schwellen können in einer Umgebung passend und in einer anderen instabil sein. Das Dokument berichtet Ping-Pong-Handovers und hält LinkStatusChanged teilweise für nicht vertrauenswürdig, weil Qualitätsabstraktion schwierig ist.

Ein Hinweis darf die alte Verbindung nicht eigenmächtig abbauen

RFC 4907 empfiehlt, Link-Indications als Hinweise und nicht als zwingende Trigger zu behandeln. Nach einem verdächtigen LinkStatusChanged kann Layer 3 den aktuellen Zustand erneut abfragen und die Bewegung abbrechen, wenn der bisherige Access Point weiter geeignet ist.

Diese Rücknahme ist keine Langsamkeit, sondern eine definierte Autoritätsgrenze. Ein schneller Controller kann Kandidaten vorbereiten, Adressen vorsondieren und eine Verbindung parallel aufbauen. Er sollte den alten Pfad aber erst an einem expliziten Commit-Punkt freigeben: Authentisierung und Link-Zustand sind belegt, Layer 3 ist konsistent, und ein geeigneter Datenpfadtest ist erfolgreich.

Die Sicherheitsbetrachtung verschärft das Argument. Gefälschte Beacons können eine korrekte PoAFound.indication auslösen und zur Assoziation mit einem bösartigen AP führen. Wechselnde gefälschte RSSI-Werte können PoAFound und PoALost wiederholt auslösen. Standardisierte Syntax authentisiert weder Beobachtung noch Kandidaten.

Fast Handover verschiebt die Beweislast nicht

RFC 5568 reduziert die Latenz des IP-Protokollteils bei Mobile IPv6, verbessert aber ausdrücklich nicht die Link-Switching-Latenz. Ein vorbereiteter Tunnel beweist ebenfalls nicht, dass Pakete unmittelbar nach dem Attachment eintreffen; der neue Access Router muss die Anwesenheit des Mobile Node erkennen.

Das experimentelle Ergebnis in RFC 5184 — null oder ein verlorener ICMP-Echo-Reply bei Proben alle zehn Millisekunden — ist Evidenz für den beschriebenen Versuchsaufbau. Es ist kein Flotten-SLA für andere Treiber, Authentisierungsverfahren, Funkbedingungen, Bridges oder Anwendungen.

Operativ sollten deshalb getrennte Verteilungen vorliegen: Observation bis Entscheidung, Entscheidung bis Ack, Ack bis LinkUp, LinkUp bis IP-ready und IP-ready bis zum ersten erfolgreichen bidirektionalen Austausch. Ein Gesamtwert verschleiert, ob Radio, Authentisierung, Bridge, Adressierung, Binding oder Route den Übergang bestimmt.

Der Beleg ist eine geordnete Kette

Für einen folgenreichen Handover braucht der Beleg eine unveränderliche Operationskennung; Interface und Technologie; Treiber- und Implementierungsstand; PoA und Discovery-Herkunft; Rohmessung und Schwellen; Indication-Sequenz; Entscheidung; exakten Request; Confirm samt enger Ack-Bedeutung; Start und Ende der Link-Operation; technologiespezifisches LinkUp; Authentisierung; Adresse, Router und Route; Paketverlust, Latenz und Anwendungsergebnis; sowie Abbruch und Rollback.

Das entspricht Heng Lus Realitätsschichten. Das Symbol an einer API-Grenze, der laufende Zustand von Hardware und Code, die IP-Konfiguration und das Erleben des Nutzers liegen auf verschiedenen Ebenen. Running Code und nachfolgende Messung haben Vorrang vor einem Statusnamen.

Eine minimale gemeinsame Spezifikation muss nicht jede Technik auf einen einzigen Begriff von „up“ normieren. Sie muss die Übergänge präzise genug benennen, damit lokale Systeme ihre technologiespezifischen Belege ergänzen und freiwillig entscheiden können. Genau das leistet die Reihenfolge in RFC 5184 — solange ein Dashboard sie nicht wieder in eine einzige grüne Lampe zusammenfaltet.

Quellen

  1. RFC 5184 — HTML
  2. RFC 5184 — Klartext
  3. Informationsseite des RFC Editor
  4. Dokumentseite im IETF Datatracker
  5. Historie im IETF Datatracker
  6. Referenzen im IETF Datatracker
  7. Errata zu RFC 5184
  8. RFC 4907 — architektonische Folgen von Link-Indications
  9. Informationsseite zu RFC 4907
  10. RFC 4957 — Link-Layer-Ereignisse für Network Attachment
  11. RFC 5568 — Fast Handovers für Mobile IPv6
  12. Informationsseite zu RFC 5568
  13. RFC 5944 — IP Mobility Support for IPv4
  14. RFC 6275 — Mobility Support in IPv6
  15. RFC 4140 — Hierarchical Mobile IPv6
  16. RFC 3819 — Hinweise für Internet-Subnetz-Designer
  17. RFC 4968 — Analyse von IPv6-Link-Modellen
  18. Heng Lu — Realitätsschichten
  19. Heng Lu — minimale Spezifikation und freiwillige Adoption
  20. Heng Lu — Running Code ist primär