Zusammenfassung
- RFC 9898 ordnet fünfzehn Neighbor-Discovery-Probleme drei Ursachen zu: Multicast, Vertrauen in alle Knoten eines Links und vom Router bei Bedarf erzeugte NCEs.
- REACHABLE bestätigt nach ND-Regeln eine kürzlich geprüfte Erreichbarkeit. Es bestätigt weder Adressrecht noch Kundenidentität, ununterbrochene Autorisierung oder Anwendungserfolg.
Die Anfrage verlangte eine Person, das Netz lieferte eine Tabellenzeile. Für die fragliche IPv6-Adresse standen Link-Layer-Adresse und REACHABLE bereit. Das war ein guter Beleg dafür, dass der Router zu diesem Zeitpunkt weiterleiten konnte. Als Antwort auf „Wer durfte die Adresse nutzen?“ blieb es ein unvollständiger Satz.
Die Lücke lässt sich nicht durch stärkere Formulierungen schließen. Neighbor Discovery führt Betriebszustand. Zuteilung, Authentisierung und historische Bindung sind andere Systeme. Wer die Zeile zur Identitätsakte erklärt, überdehnt nicht nur die Technik, sondern schwächt die Untersuchung.
RFC 9898 bündelt bekannte ND-Probleme aus mehr als zwanzig RFCs. Das Informational-Dokument führt keine neue Lösung ein und warnt, dass die fünfzehn möglichen Probleme nicht in jedem Einsatz auftreten. Es zeigt aber drei wiederkehrende Ursachen: Multicast, das Vertrauensmodell eines gemeinsamen Links und Router-NCE-on-Demand.
RFC 4861 trennt Neighbor Cache, Destination Cache, Prefix List und Default Router List. Der Neighbor Cache enthält Link-Layer-Information und Erreichbarkeitszustand für on-link Unicast-Adressen. Der Destination Cache merkt sich den nächsten Hop. Prefix List und Router List beantworten wiederum andere Auswahlfragen. Gemeinsame Implementierung bedeutet nicht gemeinsame Beweisaussage.
Fehlt die Link-Layer-Adresse, entsteht eine NCE im Zustand INCOMPLETE. Der Knoten sendet eine multicast Neighbor Solicitation und hält Pakete zurück. Eine gültige angeforderte Neighbor Advertisement kann die Adresse eintragen, REACHABLE setzen und die Warteschlange freigeben. STALE, DELAY und PROBE steuern die weitere Prüfung.
Diese Zustände sind für Paketentscheidungen gemacht. REACHABLE sagt, dass der Vorwärtspfad zur benachbarten IP-Schicht kürzlich bestätigt wurde. STALE hält eine bekannte Adresse ohne aktuelle Bestätigung. Kein Zustand nennt Vertragspartei, Leasingrecht oder Identität. Nach Ablauf, Verdrängung oder Neustart gibt es auch keinen garantierten vollständigen Verlauf.
Das Erzeugen bei Bedarf macht den Cache zur begrenzten Ressource. Ein entfernter Angreifer kann Pakete an zahlreiche nicht existierende Adressen eines on-link Präfixes schicken. Für jede entsteht eine INCOMPLETE-Frage, obwohl der Angreifer nie am lokalen Link teilnimmt. Speicher, CPU und Auflösungsarbeit werden verbraucht.
Damit ist die Zahl der Einträge kein Bestand realer Hosts. INCOMPLETE kann nur einen erfolglosen Versuch beschreiben. Ein fehlender Eintrag beweist ebenfalls keine Abwesenheit: Timeout, Garbage Collection, Limit, Neustart oder ausbleibender Verkehr führen zum gleichen Bild.
RFC 9898 nennt drei Folgen. NCE-Erschöpfung bedroht die Plattform. Reaktive Auflösung verzögert den ersten Datenverkehr und kann Pakete verlieren. Adresszurechenbarkeit bleibt lückenhaft, weil SLAAC-Adressen vom Host gebildet werden und dem Router erst bei Bedarf bekannt werden. DHCPv6 allein liefert dem Forwarding-System ohne Snooping oder Registrierung keinen vollständigen Verlauf.
Die Maßnahmen dürfen nicht zu einem grünen Sammelstatus verschmelzen. RFC 6583 empfiehlt Filter für ungenutzten Raum, Rate Limits und Vorrang für bestehende NCEs. Das schützt Kapazität. Ein Interface-Limit stoppt Wachstum, kann bei zu vielen legitimen Adressen aber gültigen Verkehr treffen. Es erzeugt keine Identität.
RFC 9131 verringert die Erstpaket-Lücke. Gratuitous Neighbor Discovery kann vor eintreffendem Rückverkehr eine STALE-NCE am First-Hop-Router anlegen. Damit liegt Link-Layer-Information bereit. Weder aktuelle Erreichbarkeit noch Berechtigung sind dadurch bestätigt.
SAVI bindet eine Adresse an einen L2-Port und verwirft widersprechende Ansprüche. RA-Guard begrenzt Router Advertisements auf erlaubte Ports. DHCPv6-Registrierung meldet selbst erzeugte oder statische Adressen an die Verwaltung. RFC 9099 ordnet mehrere Sicherheitsfragen ein. Jeder Kontrollpunkt liefert einen eigenen Beleg und kann die anderen nicht vertreten.
RFC 9898 erkennt Isolation als gemeinsame Architektur. L3+L2-Isolation gibt jedem Host Subnetz und Link, verkleinert Multicast- und Vertrauensdomäne und beseitigt Router-NCE-on-Demand für Hostrouten. L3-Isolation nutzt ein eindeutiges Präfix je Host oder Client, kann aber ein Medium teilen. Partielle L2-Isolation teilt Multicastdomänen mit Proxies. Nicht isolierende Lösungen behandeln Einzelprobleme.
Stärkere Isolation fordert Fähigkeiten und verändert Dienste. Viele logische Interfaces, der Router als Engpass und gestörtes Host-Multicast sind mögliche Kosten. RFC 8273 weist darauf hin, dass dasselbe eindeutige Präfix für dieselbe Link-Layer-Adresse Tracking erleichtern kann. RFC 9663 zeigt skalierbare Client-Präfixe mit DHCPv6-PD; Skalierbarkeit entscheidet jedoch nicht über Datenschutz.
Belastbare Zuordnung verbindet getrennte Ereignisse: Präfixzuteilung mit Gültigkeit und Aussteller; Zugriffssitzung mit Authentisierung und Circuit, Port oder Bearer; SAVI-Bindung oder DHCPv6-Registrierung; danach die NCE-Änderung mit Interface, IPv6-Adresse, Link-Layer-Adresse, Zustand, Grund und Uhrqualität. Paket- und Anwendungsprotokolle schließen spätere Grenzen.
Zeit gehört in den Schlüssel. Eine nachträglich ausgelesene Zuordnung darf nicht rückwirkend gelten. Temporäre Adressen, MAC-Randomisierung, Wiederverbindung, Failover oder Cache Refresh können Teile der Zeichenfolge erhalten, während die Identität wechselt. Fehlende Aufbewahrung ist eine Unsicherheit, keine Einladung zur Rekonstruktion.
Heng Lus Running-Code Primacy teilt Autorität nach direkter Beobachtung. Der Router belegt seinen Cache-Übergang. Das Zugangssystem belegt die authentisierte Sitzung. Der Delegationsdienst belegt das ausgegebene Präfix. Die Anwendung belegt ihre Transaktion. Bedienkomfort erweitert keine Zuständigkeit.
Die Realitätsebenen verhindern, dass eine Darstellung ihr Objekt ersetzt. Die Trennung von technischer Kontrolle und praktischer Souveränität verhindert, dass Weiterleitung zum Titel wird. Eine minimale Anfangsspezifikation hält ND interoperabel und lässt Isolation, Budget, Datenschutz, Aufbewahrung und Rollback beim Betreiber.
Die Führungsfrage lautet deshalb: Welches System beobachtete welche Beziehung in welchem Zeitraum, und welcher unabhängige Datensatz verbindet den lokalen Forwarding-Zustand mit dem verantwortlichen Prinzipal?
Sources
- https://www.rfc-editor.org/rfc/rfc9898.html
- https://www.rfc-editor.org/rfc/rfc4861.html
- https://www.rfc-editor.org/rfc/rfc6583.html
- https://www.rfc-editor.org/rfc/rfc9099.html
- https://www.rfc-editor.org/rfc/rfc9131.html
- https://www.rfc-editor.org/rfc/rfc8273.html
- https://www.rfc-editor.org/rfc/rfc9663.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/on-data-sovereignty-technical-vs-practical-realities/
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

