Zusammenfassung

  • Ein am 4. September veröffentlichter Erfahrungsbericht erläutert FreeBSDs GRAND-Implementierung anhand von Änderungen aus dem März. Das ist weder ein neuer Release noch ein unabhängiger Leistungsnachweis.
  • Vorbeugende Adressankündigungen und verzögerte Antworten dürfen dieselbe Infrastruktur nutzen, ohne deshalb dieselben Kontingente oder Aufbewahrungsregeln zu bekommen. Genau diese Unterscheidung macht die Arbeit für Betreiber interessant.

Ein kleiner Zeitvorsprung mit einer großen Bedingung

Die erste Nachricht einer neuen Verbindung kann einen Router passieren, obwohl diesem für den Rückweg noch eine Zuordnung fehlt. Der Host kennt seinen Router bereits; der Router kennt aber möglicherweise die Link-Layer-Adresse zur neuen globalen IPv6-Adresse des Hosts noch nicht. Trifft das Antwortpaket ein, muss er diese erst ermitteln. Aus einer scheinbar startklaren Verbindung wird für einen Moment ein Wartezustand.

GRAND, kurz für Gratuitous Neighbor Discovery, soll die dafür nötige Information früher bereitstellen. Der Host kündigt seine Adresse an, bevor ein Router sie für den Rückweg nachfragen muss. Im Bericht vom 4. September beschreibt Seyed Pouria Mousavizadeh Tehrani die Umsetzung in FreeBSD. Der aktuelle Anlass ist diese Erläuterung. Die verlinkten Implementierungsänderungen stammen aus dem März 2026. Aus dem Veröffentlichungsdatum des Berichts lässt sich keine neue Release-Verfügbarkeit ableiten.

Auch die Problemstellung verlangt eine Einschränkung: Fehlende Nachbarinformationen bedeuten nicht zwangsläufig, dass jedes erste Paket verloren geht. RFC 4861 verlangt, während der Adressauflösung mindestens ein Paket für das betreffende Ziel zu puffern. Eine frühe Ankündigung kann den Auflösungsschritt und damit Wartezeit beziehungsweise ein bedingtes Verlustrisiko vermeiden helfen. Sie ist kein allgemeiner Zustellnachweis.

Die Nachricht allein genügt nicht

Das Verfahren beruht auf RFC 9131. Ein Host soll bei einer neuen globalen Adresse unaufgeforderte Neighbor Advertisements an die Multicast-Adresse aller Router senden. Anzahl und zeitliche Abstände sind begrenzt; für den Abstand ist der RetransTimer maßgeblich. Auf der anderen Seite muss der Router mit einer solchen Vorabinformation auch etwas anfangen können.

Fehlt der passende Cache-Eintrag, soll ein Router bei einer gültigen Ankündigung mit der erforderlichen Link-Layer-Adressinformation einen Eintrag anlegen. Dessen Anfangszustand muss STALE sein. Das Verfahren definiert weder die Behandlung bereits vorhandener Einträge komplett neu, noch authentifiziert es den Absender. Vor allem macht es die Ankündigung nicht zuverlässig: Sie kann verloren gehen, und ein später gelöschter oder wegen Inaktivität entfernter Cache-Eintrag entsteht nicht durch das bloße Fortbestehen der Host-Adresse erneut. Die gewöhnliche Nachbarauflösung bleibt erforderlich.

Der FreeBSD-Commit vom 5. März umfasst unter anderem Ankündigungen nach abgeschlossener Duplicate Address Detection einer neuen globalen Adresse, Reaktionen auf Änderungen der Link-Layer-Adresse und eine Warteschlangenbasis für verzögertes Senden. Im historischen Änderungsstand findet sich mit ip6.grand_count auch ein Stellpunkt für die Anzahl der Ankündigungen. Er sagt allein nichts Verlässliches über die Einstellungen sämtlicher heute eingesetzter Versionen aus.

Gemeinsame Mechanik, unterschiedliche Verpflichtungen

Die technisch aufschlussreichere Frage lautet nicht nur, wann die zusätzliche Nachricht gesendet wird. Sie lautet, was mit anderen Nachrichten geschieht, die ebenfalls warten müssen. Neighbor Discovery kennt weitere zeitlich gesteuerte Vorgänge, etwa im Zusammenhang mit mehreren Adressen sowie Antworten für Anycast- und Proxy-Fälle. Eine gemeinsame Ablaufsteuerung spart doppelte Mechanik. Sie darf daraus aber keine gemeinsame Bedeutung aller Einträge ableiten.

Eine am 19. März übernommene Änderung macht diese Grenze ausdrücklich. Die Commit-Beschreibung unterscheidet GRAND von angeforderten Antworten und erläutert die Behandlung älterer ausstehender Ankündigungen für dieselbe Interface-Adresse, die Wiederverwendung von Speicher sowie die Freigabe anderer Einträge ohne die zusätzliche Nachhaltephase einer Ankündigung. Im Diff wird zudem beim GRAND-Kontingent nur die entsprechende Art von Einträgen gezählt.

Das ist ein kleiner, aber wichtiger Unterschied: Ein Limit, das freiwillige Vorabnachrichten begrenzen soll, ist nicht automatisch das richtige Limit für Antworten auf eingegangene Anfragen. Andernfalls könnte eine Optimierung ihre eigenen Mitbenutzer belasten. Die Ausnahme von diesem Kontingent gewährt Antworten allerdings weder unbegrenzte Ressourcen noch absolute Priorität. Ebenso wenig belegt die Änderung zwei physisch getrennte Warteschlangen.

Der Quellstand dokumentiert Absicht und Änderungen, nicht die Korrektheit jeder denkbaren zeitlichen Überlagerung. Für diesen Bericht wurde die Implementierung weder gebaut noch mit Paketmitschnitten oder Lastversuchen geprüft. Auch enthält die hier verwendete Beleglage keinen unabhängigen Vergleich produktiver Installationen. Wer den Nutzen beziffern will, muss diese Arbeit noch leisten. Die vorhandene Evidenz ist bereits nützlich, nur für eine engere Aussage: Früheres Melden braucht saubere Regeln für das gemeinsame Warten.