Zusammenfassung

  • RFC 3316 empfahl, neue TCP-Bestätigungen, RTCP-Empfangsberichte und SIP-Antworten als positiven Beleg dafür zu nutzen, dass jüngst gesendeter Verkehr den Router des ersten Hops passiert hatte.
  • Die Schlussfolgerung blieb eng: Sie konnte den Nachbarstatus auffrischen und eine NUD-Sonde vermeiden, bewies aber weder den Abschluss der Anwendung noch dauerhafte Konnektivität; beliebiger eingehender Verkehr genügte ebenfalls nicht.

Das teure Paket auf einer frühen IPv6-Mobilfunkverbindung transportierte nicht immer Nutzdaten. Manchmal stellte es nur eine Kontrollfrage, deren Antwort der Host aus einem anderen Protokoll bereits kannte.

Neighbor Unreachability Detection, kurz NUD, führt Buch darüber, ob der nächste Hop vor Kurzem erreichbar war. Läuft dieses Vertrauen ab, während weiter gesendet wird, kann der Host eine unicast Neighbor Solicitation aussenden und auf die angeforderte Neighbor Advertisement warten. Bei Ethernet liegt dieser Austausch nahe an der Adressauflösung. Die von RFC 3316 beschriebenen GPRS- und UMTS-Verbindungen sahen anders aus: Sie ähnelten Punkt-zu-Punkt-Links, der einzige Nachbar war der bereits entdeckte Standardrouter, und Link-Layer-Adressen gab es nicht. Adressauflösung war unnötig; die Erkennung eines ausgefallenen ersten Hops blieb nötig.

Das Profil stellte deshalb eine präzisere Frage: Hatte ein anderes Protokoll bereits gezeigt, dass ein kürzlich gesendetes Paket vorangekommen war?

Die allgemeine Neighbor-Discovery-Regel lieferte die Logik. Eine neue TCP-Bestätigung zeigt, dass zuvor gesendete Daten den entfernten Peer erreicht haben. Liegt dieser außerhalb des lokalen Links, konnten die Daten nicht ohne den Router des ersten Hops dorthin gelangen. Die Ende-zu-Ende-Bestätigung enthält somit eine lokale Tatsache: Als dieses Paket passierte, war der nächste Hop erreichbar. Der Host kann diese Tatsache in seinen Neighbor Cache übernehmen, statt den Router mit einem weiteren Austausch separat zu prüfen.

RFC 3316 übertrug den Gedanken auf UDP-basierte Mobilfunkanwendungen. UDP liefert selbst keine Zustellbestätigung; daher musste die Anwendung ein Signal mit der richtigen Kausalität bereitstellen. Bei RTP konnte ein RTCP-Empfangsbericht genügen, der anzeigte, dass einige Pakete beim Peer angekommen waren. Bei SIP zeigte eine Antwort, dass die vorausgehende Anfrage ihr Ziel erreicht hatte. Arbeitete der Mobilfunkhost auf der SIP-Serverseite, war das bloße Senden einer Antwort meist kein Beleg; ein später empfangenes ACK konnte dagegen zeigen, dass die Antwort auf das INVITE die Gegenstelle erreicht hatte.

Diese Signale waren keine austauschbaren grünen Lampen. Jedes musste die Zustellung kürzlich gesendeten Verkehrs voraussetzen. Ein unverbundenes eingehendes Datagramm reichte nicht. Ebenso wenig eine unangeforderte Router Advertisement: Sie belegte nur den Weg vom Router zum Host. NUD brauchte Vertrauen in die andere Richtung, vom Host über den nächsten Hop. Netzaktivität zu sehen ist nicht dasselbe wie den geprüften Vorwärtspfad zu belegen.

Auch der gewonnene Zustand war befristet. Eine Bestätigung aus einer höheren Schicht konnte den Neighbor-Cache-Eintrag für eine begrenzte Zeit auf REACHABLE setzen. Blieb neue Evidenz aus, alterte er zu STALE; beim Senden konnte er über DELAY zu PROBE wechseln, worauf dedizierte Neighbor Solicitations wieder einsetzten. RFC 3316 schaffte NUD nicht ab. Es vermied eine doppelte Frage, solange aktive Anwendungen bereits eine gültige Antwort lieferten.

Für diese Sparsamkeit gab es einen konkreten Grund. Funkbandbreite war knapp, und Nutzer konnten nach Datenmenge bezahlen. Unnötige Nachrichten zu vermeiden konnte Kapazität und Kosten schonen. Das RFC maß jedoch weder Paket-, Akku- noch Gebühreneinsparungen. Es formulierte ein Implementierungsprofil aus Linktopologie und vorhandenen Flusssignalen.

Der Mechanismus überdauerte das Dokument. RFC 7066 ersetzte RFC 3316 im Jahr 2013, ergänzte EPS, behielt die Beispiele TCP, RTCP und SIP bei und nahm DNS-Antworten hinzu. Diese Kontinuität zeigt, dass die Folgerung im Profil fortbestand; sie sagt nicht, welche Geräte sie umsetzten oder wie viele Sonden tatsächlich entfielen.

Die historische Lehre lautet nicht, Anwendungen über Routing entscheiden zu lassen. Eine Zustandsmaschine darf Evidenz aus einer anderen Schicht wiederverwenden, wenn die Implikation ausdrücklich gilt. Der Bericht des entfernten Peers sagt etwas über den ersten Hop, weil das kürzlich gesendete Paket ihn passieren musste. Weiter reicht die Aussage nicht: Ein RTCP-Bericht beweist keine gute Medienqualität, eine SIP-Antwort keinen abgeschlossenen Anruf, ein erreichbarer Router keinen verfügbaren Dienst und der Erfolg eines Pakets nicht den des nächsten.

Quellen: RFC 3316, RFC 2461, RFC 4861, RFC 7066, RFC 7849, RFC 8504, RFC 3550 und RFC 3261.