Zusammenfassung

  • Neighbor Unreachability Detection speichert eine befristete Aussage: Ein aktueller positiver Beleg zeigte, dass der Vorwärtspfad Pakete bis zur IP-Schicht des Nachbarn brachte. Läuft die Frist ab, wird REACHABLE zu STALE, auch wenn kein Paketverlust beobachtet wurde.
  • RFC 7048 kann die bekannte Link-Layer-Adresse ohne alternativen Nachbarn behalten und geduldiger prüfen. Weiterzusenden authentifiziert weder Gerät noch Eigentümer und bestätigt weder Berechtigung noch Anwendungserfolg.

Im Incident-Call steht eine scheinbar widersprüchliche Frage: Warum sendet der Host weiter, obwohl der Nachbar als UNREACHABLE geführt wird? Die falsche Antwort lautet, die Implementierung ignoriere ihren eigenen Befund. Die bessere Antwort beginnt damit, den Befund enger zu lesen.

Der Zustand sagt nicht, dass kein Paket mehr ankommen kann. Er sagt, dass der vorgesehene Prüfmechanismus keine frische positive Bestätigung erhalten hat. Wenn keine andere Route existiert, kann es sinnvoll sein, die einzige bekannte Link-Layer-Adresse weiterzuverwenden und die Prüfungen auszudehnen. Erinnerung und Gewissheit sind nicht dasselbe.

Erik Nordmark gehört zur dokumentierten Normengeschichte dieser Trennung. Er ist einer von vier Autoren von RFC 4861, dem Standards-Track-Dokument für IPv6 Neighbor Discovery. Bei RFC 7048, der ein zu ungeduldiges NUD-Verhalten korrigiert, steht sein Name an erster Stelle der zwei Autoren. Außerdem wirkte er an RFC 3756 mit, einer Informational-Analyse von Vertrauensmodellen und Bedrohungen. Diese Angaben belegen Beteiligung an kollektiver IETF-Arbeit. Sie belegen weder Alleinerfindung noch die Konformität einer konkreten Implementierung oder Verfügungsgewalt über Betreiberentscheidungen.

Erreichbarkeit ist ein gerichteter, befristeter Satz

RFC 4861 definiert Erreichbarkeit aus Sicht des sendenden Knotens. Es muss einen positiven Beleg geben, dass der einseitige Vorwärtspfad funktioniert: Gesendete Pakete erreichen die IP-Schicht des Nachbarn und werden dort ordnungsgemäß verarbeitet. Bei einem benachbarten Router umfasst der Satz auch, dass dieser als Router weiterleitet.

Das ist weniger als „der Dienst ist gesund“. Es beweist keine Pfadsymmetrie, keine Verfügbarkeit jeder Zwischenkomponente, keine Identität des Gerätehalters und keinen Abschluss einer Anwendungstransaktion. Es ist eine Aussage über einen bestimmten nächsten Hop innerhalb eines definierten Frischeintervalls.

NUD kennt zwei Hauptquellen positiver Bestätigung. Eine angeforderte Neighbor Advertisement kann auf eine Neighbor Solicitation antworten. Oder ein höheres Protokoll liefert einen geeigneten Hinweis auf Vorwärtsfortschritt.

Ein neues TCP-Acknowledgement kann zeigen, dass kürzlich gesendete Daten den entfernten Peer erreicht haben. Läuft die Route über den Nachbarn im Cache, stützt dies die Folgerung, dass der erste Hop funktioniert hat. Neue, nicht duplizierte Daten können umgekehrt zeigen, dass frühere Bestätigungen vorangekommen sind.

Der Schluss bleibt auf diesen Zweck begrenzt. Ein TCP-ACK authentifiziert nicht die Link-Layer-Identität, bestätigt keine Rückweg-Symmetrie und sagt nichts darüber, ob eine Geschäftsoperation autorisiert oder abgeschlossen wurde. Ein Beleg darf zwischen Schichten genutzt, aber nicht in eine umfassendere Behauptung umbenannt werden.

STALE bezeichnet das Alter des Wissens

INCOMPLETE bedeutet, dass die Adressauflösung noch keine nutzbare Link-Layer-Adresse geliefert hat. REACHABLE bedeutet, dass eine positive Bestätigung noch frisch ist. Mit Ablauf des Timers wechselt der Eintrag zu STALE. Die gespeicherte Adresse bleibt erhalten; nur der stärkere Satz über aktuelle Erreichbarkeit verliert seine Grundlage.

Ein unbenutzter STALE-Eintrag sendet nicht allein wegen seines Alters. Erst ein neues Paket macht ihn zu DELAY. Das Paket kann über die bekannte Adresse hinausgehen. Während der kurzen Verzögerung kann eine höhere Schicht neue Bestätigung liefern und damit zusätzliche Neighbor-Discovery-Pakete vermeiden.

Bleibt die Bestätigung aus, folgt PROBE. Der Knoten sendet unicast Neighbor Solicitations an die bekannte Link-Layer-Adresse. Eine gültige angeforderte Neighbor Advertisement kann REACHABLE wiederherstellen. Im Basisablauf führt ein ausgeschöpftes Probe-Limit zur Löschung des Eintrags und zu neuer Next-Hop-Bestimmung oder Adressauflösung.

Die Zustände trennen gespeicherte Ortsinformation, Belegfrische, aktuellen Nutzungsbedarf und aktive Nachprüfung. Ein einzelnes last_seen verwischt sie. Wurde ein unaufgefordertes Paket gesehen? Kam ein TCP-Fortschrittshinweis? Antwortete der Nachbar auf eine Sonde? Ohne Mechanismus und Richtung sagt der Zeitstempel zu viel und zu wenig zugleich.

Eine Nachricht aus der Gegenrichtung bestätigt nicht den Hinweg

Router Advertisements und unaufgeforderte Neighbor Advertisements können wichtige Informationen liefern. Eine Link-Layer-Adresse kann sich geändert haben; ein Router kann sich ankündigen. Diese Nachrichten zeigen jedoch zunächst nur, dass etwas vom Nachbarn zum Empfänger gelangt ist. NUD fragt nach dem Weg vom Empfänger zum Nachbarn.

Darum dürfen Router Advertisements und Neighbor Advertisements mit gelöschtem Solicited-Bit laut RFC 4861 nicht als Erreichbarkeitsbestätigung gelten. Wer eine Stimme hört, weiß noch nicht, ob die andere Seite ihn hört. Wer eine Anschrift lernt, weiß noch nicht, ob der Brief ankommt.

Ein Monitoringdienst, der bei jeder Nachricht last_reachable_at erneuert, beseitigt diese Richtungsinformation. Ein spontanes Signal kann den Status grün halten, ohne die Vorwärtspfad-Frage zu beantworten. Der belastbare Datensatz hält Solicited-Bit, Richtung, Interface, Zieladresse, Link-Layer-Änderung und erlaubten Zustandsübergang auseinander.

„Nachbarinformation empfangen“ und „Vorwärtserreichbarkeit bestätigt“ sind zwei Ereignisse. Automatisierung darf sie nicht zusammenführen, nur weil sie im selben Protokoll vorkommen.

Schnelles Scheitern braucht ein brauchbares Danach

RFC 7048 beschreibt als Ausgangspunkt drei Übertragungen im Abstand von etwa einer Sekunde. Hat ein Host einen anderen Default-Router, kann dieser kurze Zeitraum sinnvoll sein. Der derzeitige Nachbar wird aufgegeben, damit ein wirklich anderer Pfad genutzt werden kann.

Ohne Alternative ist derselbe Timer oft kontraproduktiv. Eine kurze Funkstörung, ein schlafender Link oder langsame Erholung kann das Limit überschreiten. Die Löschung löst neue, häufig multicast-basierte Auflösung aus und verwirft zugleich die einzige plausible Link-Layer-Adresse. Der Host fällt nicht auf Redundanz zurück; er erzeugt nur zusätzliche Arbeit.

Für diesen Fall beschreibt RFC 7048 einen konzeptionellen Zustand UNREACHABLE. Eintrag und Link-Layer-Adresse können erhalten bleiben. Pakete dürfen weiter an diese Adresse gehen. Neighbor Solicitations laufen mit exponentiellem Backoff weiter und müssen schließlich von Unicast zu Multicast wechseln. Das ist nötig, weil sich die Link-Layer-Adresse geändert haben könnte und endlose Unicast-Sonden zur alten Adresse dies nie erkennen würden.

UNREACHABLE heißt hier nicht „jede Übertragung eingestellt“ oder „Dienst endgültig ausgefallen“. Es heißt, dass die aktive Prüfung keine Bestätigung bekam. Sobald ein brauchbarer alternativer Next Hop vorhanden ist, darf der unbestätigte Eintrag dessen Auswahl nicht verhindern. Ein durch Redirect entstandener Eintrag kann sogar gelöscht statt erhalten werden.

Geduld ist deshalb keine pauschal höhere Zuverlässigkeit. Ohne Alternative kann sie Kontinuität bewahren. Mit Alternative kann sie den sinnvollen Failover verzögern. Entscheidend ist nicht der Zustandsname, sondern die im Entscheidungszeitpunkt nachgewiesene Alternativenmenge.

Ein korrekter Übergang kann auf einer Fälschung beruhen

RFC 3756 zeigt die Sicherheitsgrenze. Wo ein Angreifer Neighbor-Discovery-Nachrichten einspeisen kann, kann eine gefälschte angeforderte Neighbor Advertisement falsche positive Bestätigung erzeugen. Der Cache kann auf eine bösartige oder nicht existente Link-Layer-Adresse zeigen und den Verkehr dort festhalten. Der Automat hat seine Regel korrekt ausgeführt; seine Eingabe war feindlich.

REACHABLE ist daher kein Synonym für authentifiziert. Eine IPv6-zu-Link-Layer-Zuordnung benennt auch nicht automatisch Eigentümer, Organisation, Firmware oder Zulassungsrichtlinie. Linkzugang, Kryptografie, Inventar und Anwendungsautorisierung liefern jeweils eigene Belege.

Ein Incident-Ledger stellt diese Belege nebeneinander. Für NUD hält es Interface, Next Hop, Zuordnung, Bestätigungsquelle, Probe-Folge, verfügbare Alternativen, Sicherheitskontext und Implementierungsversion fest. Für die Anwendung hält es getrennt den authentifizierten Principal, die Berechtigungsentscheidung, Ressourcenversion und Ergebnisquittung fest. Eine Neighbor-Antwort darf diese Felder nicht stellvertretend ausfüllen.

Präzise Zuschreibung schützt auch den Autor

Das am 30. August 2026 geprüfte IETF-Profil führt 25 RFCs und eine aktive Gutachterrolle im Internet of Things Directorate für Nordmark auf. Diese Profilangaben können sich ändern. Dauerhafter sind die Dokumentköpfe: Thomas Narten, Nordmark, William Simpson und Hesham Soliman bei RFC 4861; Nordmark und Igor Gashinsky bei RFC 7048; Pekka Nikander als Herausgeber, James Kempf und Nordmark bei RFC 3756.

RFC 4861 und RFC 7048 sind Standards Track. RFC 3756 ist Informational. Weder Reihenfolge noch Dokumentstatus beweisen, dass eine konkrete Software die Regeln richtig umsetzt. Laufender Code muss zeigen, welche Hinweise akzeptiert, welche Zustände durchlaufen, welche Alternativen gewählt und welche Daten protokolliert werden.

Eine RFC ist ein öffentlicher Koordinationspunkt. Sie macht Verhalten vergleichbar, betreibt es aber nicht. Genau diese Begrenzung ist auch die Stärke von NUD: Das Verfahren behält eine nützliche Zuordnung, senkt aber die behauptete Sicherheit, sobald der Beleg altert.

Nicht der Nachbar wurde alt. Der Beleg wurde alt. Wer das im Protokoll und im Bericht trennt, kann Kontinuität zulassen, ohne Gewissheit zu erfinden.

Quellen