Zusammenfassung

  • RFC 1788 definierte die ICMP-Typen 37 und 38, um jede Unicast-Adresse direkt nach ihren Domainnamen zu fragen und die Abhängigkeit vom getrennt verwalteten Reverse DNS zu verringern.
  • Quelladresse, Kennung, Sequenz, TTL, leere Antwort und MTU-Auslassung begrenzten einen einzelnen Beleg; Eigentum, Person, Routenberechtigung oder institutionelle Identität bewiesen sie nicht.
  • RFC 6918 stufte die Nachrichten 2013 als veraltet ein, weil sie nie breit implementiert oder eingesetzt worden waren. Laufender Code entschied anders als das universelle MUST.

Vollständigkeit endete an der Paketgrenze

Eine Domain Name Reply durfte null, einen oder mehrere vollständig qualifizierte Namen enthalten. Waren mehrere bekannt, sollten alle genannt werden. Doch ein Name, der nicht in die Antwort-MTU passte, wurde ausgelassen. Der Empfänger konnte daher nicht allein aus der Liste folgern, dass der Knoten keine weiteren Namen kannte.

Diese kleine Regel ist für die Geschichte zentral. RFC 1788 wollte Unsicherheit verringern, nicht beliebige Identitätsbehauptungen erzeugen. Das Paket war ein begrenzter Beleg: Was antwortete dieser Endpunkt auf diese Frage, unter diesen Größen- und Zeitbedingungen?

Auch der TTL hatte einen engen Zweck. Er war aus historischen Gründen als vorzeichenbehafteter Zweierkomplementwert definiert und gab an, wie lange die Namensinformation wiederverwendet werden konnte. Er bestätigte weder die semantische Richtigkeit des Namens noch den Fortbestand einer Route, eines Geräts oder einer Organisation.

Reverse DNS folgte einer anderen Verwaltung

Der Ausgangspunkt war kein erfundenes Problem. IN-ADDR-Daten wurden nicht zuverlässig gepflegt. Vorwärtsnamen folgen der Domainverwaltung; Reverse-Zonen folgen der Zuteilung und Delegation von Adressraum. Mit CIDR verliefen diese Grenzen noch sichtbarer auseinander.

Anwendungen, die einen Namen für eine Oberfläche oder ein Sicherheitsprotokoll suchten, konnten lange auf eine erfolglose Rückwärtsauflösung warten. RFC 1788 schlug deshalb vor, die Adresse selbst zu befragen. Routing sollte die Datenbank indizieren, indem es die Anfrage an den Rechner lieferte, der die Adresse verwendete.

Damit wanderte die Verwaltungsnaht. Sie verschwand nicht. Ein Betriebssystem musste wissen, welche Namen es nennt. Hersteller mussten den Server ausliefern. Betreiber mussten die Nachrichten zulassen. Anwendungen mussten Frische und Vertrauen bewerten. Eine erreichbare Adresse war noch keine legitimierte Namensstelle.

Typ 37 fragte, Typ 38 antwortete

Die Anfrage erhielt ICMP-Typ 37, die Antwort Typ 38. Kennung und Sequenznummer wurden zum Zuordnen zurückkopiert und durften null sein. Jede IP-Zieladresse wurde separat befragt.

Die Quelladresse der Antwort musste genau der Zieladresse der Anfrage entsprechen. Wer A fragte, sollte keinen Ersatzbeleg aus B erhalten. Diese Regel verband die beobachtete Antwort mit der angesprochenen Schnittstelle.

Sie bewies nicht, wem A gehörte, wer das Gerät bediente oder ob die Route zu A autorisiert war. Sie bewies auch keine Vorwärtsauflösung und keine organisatorische Vertretungsmacht der antwortenden Software. Technische Gleichheit zweier Adressfelder ist keine vollständige Identitätskette.

RFC 1788 zog die Sicherheitsgrenze selbst. Routing sei kein Sicherheitsmechanismus. IPsec könne den Austausch schützen; eine kryptographische Signatur aus dem Vorwärts-DNS könne eine Antwort prüfen. Diese zusätzlichen Möglichkeiten waren gerade nicht im ungeschützten Basisaustausch enthalten.

Kein Name war eine absichtliche Antwort

Kannte der Knoten keinen Namen, musste er dennoch antworten. Die leere Reply sollte verbindlich anzeigen, dass kein Name bekannt war. Für eine Anwendung war das besser als Schweigen: Sie konnte eine ausdrückliche negative Auskunft von einem verlorenen Paket unterscheiden.

„Verbindlich“ blieb auf den antwortenden Knoten und das Protokoll beschränkt. Die leere Liste war kein DNSSEC-Negativbeweis, kein Eigentumsnachweis und keine ewige Aussage. Morgen konnte die Konfiguration anders sein; bereits heute konnte die Software irren oder unberechtigt sprechen.

Hier zeigt sich Heng Lus Unterscheidung der Realitätsebenen. Das Paket ist beobachtbar. Die Aussage „diese Institution kontrolliert die Adresse“ ist eine zusätzliche Deutung. Wer im Log nur „Identität bestätigt“ speichert und Ziel, Quelle, Zeit, TTL, Authentisierung und Antwortinhalt verwirft, macht das Symbol stärker als die Realität darunter.

Multicast hätte die Pflicht vervielfacht

Anfragen an Broadcast- oder Multicast-Ziele mussten still verworfen werden. Würde jeder Empfänger der universellen Serverpflicht folgen, könnte eine Gruppenanfrage einen Antwortsturm auslösen.

Das universelle „jeder Host und Router“ hatte also einen eng gefassten Auslöser: ein Unicast-Ziel, eine Anfrage, ein Rückweg. Erkennung durfte nicht durch Fan-out zur Verstärkung werden.

Selbst innerhalb dieser Grenze war die Koordinationsfläche groß. Betriebssysteme, Router, eingebettete Geräte, Firewalls, Diagnoseprogramme und Anwendungs-Schnittstellen mussten mitziehen. RFC 1788 empfahl eine solche Schnittstelle ausdrücklich. Ein kurzes Nachrichtenformat bedeutete keine kleine Einführung.

Schweigen über ICMP hatte mehrere Ursachen

RFC 792 hatte bereits erklärt, dass ICMP Rückmeldung liefert, IP aber nicht zuverlässig macht. Weder das ursprüngliche Datagramm noch eine Kontrollnachricht ist garantiert.

Ein Timeout bewies daher nicht, dass RFC 1788 fehlte. Verlust, Filter, Richtlinie oder Routenänderung konnten dasselbe Bild erzeugen. Umgekehrt bewies eine korrekte Antwort nur, dass auf diesem Pfad zu diesem Zeitpunkt eine Implementierung geantwortet hatte.

Positive Namen, explizite Leere, keine Antwort, administrative Sperre und fehlgeschlagene Authentisierung mussten getrennte Zustände bleiben. Genau diese Trennung sollte die leere Reply leisten. Ein Auswertungssystem, das alles als „unbekannt“ zusammenfasst, stellt die alte Ungewissheit wieder her.

Ein MUST installierte keinen Server

RFC 1788 formulierte die Serverfunktion nicht optional: Jeder Host und Router musste sie implementieren. Für Diagnosezwecke sollte zudem eine Anwendungs-Schnittstelle vorhanden sein. Das Ziel war allgemeine Infrastruktur.

RFC 6918 hielt 2013 das operative Ergebnis fest. Die Typen 37 und 38 seien nie breit implementiert oder eingesetzt worden. Das Standards-Track-Dokument erklärte sie für Deprecated, machte RFC 1788 obsolet und bemerkte, die Einstufung könne das Filtern unterstützen. Der heutige IANA-Eintrag trägt diesen Status.

Die genaue Formulierung zählt. „Nie breit“ heißt nicht „niemals irgendwo“. Die Quellen nennen auch keinen einzigen Grund. Sie belegen, dass keine genügend dichte Population entstand, auf die Anwendungen als allgemeinen Dienst bauen konnten.

Die Anreize liefen im Kreis. Ohne viele Server sahen Anwendungen zu viele Timeouts. Ohne Anwendungen sahen Hersteller wenig Nutzen. Middleboxes konnten unbekannte ICMP-Typen blockieren. DNS-Schnittstellen waren vorhanden. Direkte Knotenantworten brachten zudem Datenschutz-, Authentisierungs- und Mehrnamenfragen mit.

Mit der formalen Abwertung wurde die Pflege noch weniger attraktiv. Der Standard beschrieb nicht nur den erreichten Zustand; er gab Betreibern einen weiteren Grund, die Restfläche zu schließen.

IPv6 kam mit kleinerem Anspruch zurück

RFC 4620 definierte später experimentelle IPv6 Node Information Queries und verwies auf den IPv4-Vorläufer. Es begrenzte den Zweck jedoch auf Diagnose, Fehlersuche und Netzverwaltung. Für globale Namensautorität blieb DNS zuständig.

Das Protokoll verwendete eine Nonce, schränkte den Standardbereich ein, behandelte Datenschutz und Rate Limits und warnte davor, gelernte Daten ohne zusätzliche Authentisierung für Sicherheitsentscheidungen zu verwenden. Für Knotennamen musste der TTL null sein.

Das war keine heimliche Fortsetzung von RFC 1788 und kein Beleg für breite IPv6-Verbreitung. Es war ein anderes Experiment, dessen engerer Anspruch zeigte, wie vorsichtig direkte Selbstauskunft behandelt werden musste.

Die eigentliche Abstimmung fand im Betrieb statt

Heng Lus Running-Code Primacy liefert den passenden heutigen Blick. Eine Spezifikation kann festlegen, wie sich eine konforme Implementierung verhalten muss. Operative Autorität entsteht aber erst, wenn unabhängig kontrollierte Systeme sie freiwillig übernehmen und tatsächlich interoperieren.

RFC 1788 besaß die symbolische Schicht: RFC-Nummer, zugeteilte Typen, Paketformat und universelle Norm. Ihm fehlte die operative Schicht mit genügend erreichbaren Antworten. Achtzehn Jahre später wurde das Symbolregister an diese Wirklichkeit angepasst.

Minimum Initial Specification, Localized Future Decision und Voluntary Adoption ergänzen eine wichtige Messung. Das Drahtformat war klein, die Einführungsentscheidung nicht. Sie musste in fast jedem Host, Router, Filter und Programm wiederholt werden. Wenige Felder können eine weltweite Koordinationslast tragen.

Das ist eine heutige Deutung, kein Beweis für die Motive der Autoren von 1995. Es ist auch kein Argument gegen MUST. In einem angenommenen Protokoll machen starke Anforderungen Interoperabilität möglich. Die Wortstärke darf nur nicht als Nachweis gelten, dass die Annahme bereits erfolgt ist.

RFC 1788 wusste, was aus einer einzelnen Antwort verschwinden durfte. Es konnte nicht bestimmen, wie viele Antworten aus der Welt ganz ausbleiben würden. Die MTU begrenzte die Namensliste; der laufende Code begrenzte den Standard.

Quellen