Zusammenfassung

  • RFC 4620 gab IPv6-Diagnosewerkzeugen eine direkte Abfrage für ausgewählte Namen oder Adressen, besonders auf Verbindungen ohne DNS oder globale Routen.
  • Der Knoten durfte die Antwort verweigern. Sie blieb eine lokale Selbstauskunft, keine bestätigte Identität und kein maßgeblicher Verzeichniseintrag.

Analyse

Eine automatisch konfigurierte IPv6-Adresse kann funktionieren, ohne dass der Betreiber das zugehörige Gerät leicht erkennt. Beim Einrichten einer Verbindung oder bei der Fehlersuche steht auf dem lokalen Segment vielleicht kein DNS zur Verfügung. Eine linklokale Adresse muss auch nicht in einer öffentlichen DNS-Zone erscheinen. Trotzdem kann eine direkte Frage an den erreichbaren Knoten nützlich sein: Welchen Namen oder welche weiteren Adressen ordnet er sich selbst zu?

Im August 2006 beschrieben Michael Crawford und Brian Haberman diese Möglichkeit in RFC 4620. Der RFC war als Experimental eingestuft und begrenzte den Einsatz auf Diagnose, Fehlersuche und Netzwerkverwaltung. Für Namen und Adressen im globalen Internet blieb DNS ausdrücklich die maßgebliche Quelle. Die Node-Information-Abfrage sollte also kein zweites globales Namensverzeichnis schaffen. Sie war als Werkzeug gedacht, wenn DNS oder globale Weiterleitung auf einer Verbindung fehlten.

Die Nachricht lief über ICMPv6: Typ 139 für eine Abfrage und Typ 140 für eine Antwort. Die Abfrage bezeichnete sowohl den angesprochenen Knoten als auch das erfragte Subjekt; beide Adressen konnten voneinander abweichen. Die definierten Qtypes umfassten eine Anfrage ohne Daten, den Knotennamen, IPv6-Adressen und IPv4-Adressen. Flags der Adressabfrage begrenzten die gewünschten Bereiche und legten fest, ob alle Adressen angefordert wurden. Ein Diagnosewerkzeug konnte damit erfragen, was der aktive Endpunkt meldete, ohne anzunehmen, die Antwort beschreibe jede Schnittstelle vollständig.

Eine Ablehnung war ein fest vorgesehenes Ergebnis. Der Antwortcode unterschied Erfolg, Ablehnung und einen unbekannten Abfragetyp. Selbst eine erfolgreiche Antwort durfte leer sein. Keine Antwort, Ablehnung, unbekannter Typ und leere Antwort bedeuten deshalb Verschiedenes; für sich genommen beweist keines davon, dass der Knoten nicht existiert. Der Empfänger prüfte außerdem, ob die Zieladresse eine eigene Unicast- oder Anycast-Adresse oder eine beigetretene linklokale Multicast-Gruppe war. Eine lokale Richtlinie durfte die Anfrage verwerfen.

Ein 64-Bit-Nonce wurde in der Antwort gespiegelt, damit der Absender sie der Anfrage zuordnen und blinde Fälschungen erschweren konnte. Die Autoren benannten die Grenze: Wer die Nachrichten mitlesen konnte, konnte diesen Schutz umgehen. Für echte Kommunikationssicherheit empfahlen sie IPsec. Sicherheitsrelevante Entscheidungen sollten die erhaltenen Informationen nur mit einem zusätzlichen Authentisierungsverfahren verwenden.

Auch die Offenlegung blieb begrenzt. Standardmäßig musste eine Implementierung Anfragen von globalen Quelladressen ablehnen. Der RFC empfahl eine Ratenbegrenzung und eine Steuerung der Offenlegung temporärer IPv6-Datenschutzadressen. IANA führt die Typen 139 und 140 weiterhin. Ein Registereintrag beweist jedoch nicht, dass beliebige Hosts antworten. RFC 4620 nannte ping6 aus KAME, USAGI und weiteren IPv6-Implementierungen als Diagnosebeispiel. Nmap dokumentiert heute ebenfalls ein Discovery-Skript für diese Abfragen. Das belegt Werkzeugfunktionen, aber keine breite Nutzung in Netzen.

Der historische Beitrag von RFC 4620 war bewusst begrenzt: Die Selbstauskunft eines Knotens wurde für die Fehlersuche abfragbar, während Ablehnungsrecht und Beweisgrenzen sichtbar blieben. Eine Antwort bewies weder, wer das Gerät kontrollierte, noch wem ein Name gehörte oder welche Organisation dahinterstand. Sie ersetzte kein maßgebliches Anlagenverzeichnis.

Quellen