Zusammenfassung

  • Kann die Quelladresse der Antwort den Ursprungsknoten eines erfassten ICMP-Fehlers nicht ausreichend erkennen lassen, verlangt Revision 05 ein Node Identification Object – sofern lokale Richtlinien oder Sicherheitsgründe nicht Vorrang haben.
  • Adresse oder Name können im jeweiligen Betriebsbereich nützlich sein und Vorübersetzungs-Kontext erhalten. Das Objekt bietet jedoch keine Authentifizierung und lässt sich fälschen.
  • Würde der Zusatz die Next-Hop-MTU überschreiten, können Bytes aus dem zitierten Ursprungsdatagramm weichen. Knoten- und Korrelationsvertrauen gehören deshalb in getrennte Nachweise.

Ein Feld löst nicht beide Fragen

Bei einem ICMP-Fehler will der Betreiber wissen, wo er entstand und zu welchem Paket er gehört. Die äußere Quelladresse liefert einen Herkunftshinweis; das zitierte Stück des auslösenden Pakets ermöglicht Korrelation. An Übersetzungsgrenzen kann der erste Hinweis an Bedeutung verlieren. Unter Größenbeschränkung kann der zweite schrumpfen.

Der Datatracker-Eintrag führt draft-ietf-intarea-extended-icmp-nodeid als aktiven INTAREA-Arbeitsgruppenentwurf für den Standards Track, derzeit im Nachgang zur AD Evaluation. Revision 05 stammt vom 7. September 2026. Sie ist weder RFC noch IESG-Freigabe oder Einsatznachweis.

Für ausgewählte ICMPv4- und ICMPv6-Fehler definiert der Entwurf ein Objekt mit Adresse, Knotenname oder beidem. Gegenüber Revision 04 wurde SHOULD zu MUST: Reicht die Antwortadresse möglicherweise nicht aus, muss das Objekt mitgesendet werden, außer eine lokale oder sicherheitsbezogene Entscheidung untersagt es. Regeln für leere aktuelle Bits, künftige Bitvergabe, UTF-8-Kürzung und MTU werden ebenfalls präziser.

Die Spezifikation macht das Auftreten verlässlicher, nicht den Inhalt wahrer.

Bedeutung braucht einen Geltungsbereich

C-Type-Bits legen Inhalt und Reihenfolge der Teilobjekte fest. Erkennt ein älterer Empfänger ein künftiges Teilobjekt nicht und kennt dessen Länge nicht, kann er ein dahinter angekündigtes bekanntes Feld nicht sicher finden. Zusätzliche Daten sind dann zu ignorieren. Reservierte Bits allein schaffen keine überspringbare Zukunftsstruktur.

Eine lokale Adresse kann innerhalb ihrer Domäne äußerst aussagekräftig sein. RFC 4193 zeigt dies für Unique Local IPv6 Addresses: hohe konstruktive Eindeutigkeit bedeutet nicht globale Erreichbarkeit. Ein zentrales System muss den Geltungsbereich zusammen mit dem Wert erhalten.

Knotennamen sind auf 63 Oktette begrenzt. Revision 05 verlangt, lange UTF-8-Namen an einer Zeichengrenze zu kürzen und anschließend mit NUL aufzufüllen. Das verhindert beschädigte Zeichen, garantiert aber weder eindeutige noch überprüfte Namen.

Außer bei Übersetzern ist die Funktion standardmäßig aus; eine Zielrichtlinie kann die Ausgabe weiter begrenzen. Interne Namen und Adressen verraten Struktur. Die Sicherheitsausnahme ist daher Bestandteil der Offenlegungsentscheidung. Die AD-Prüfung fragte nach Normstärke, Bereich, UTF-8 und Größe; die Antwort der Autoren begründet die Änderungen, ohne eine endgültige Genehmigung darzustellen.

Kontext vor der Übersetzung

Ein Übersetzer kennt auf der einen Seite eine Adresse, die auf der anderen nicht als normale ICMP-Quelle darstellbar ist. Das Objekt kann diesen Vorübersetzungs-Kontext tragen. RFC 7915 beschreibt zustandslose IP/ICMP-Übersetzung. Ein verwandter v6ops-Entwurf setzt bei einer nicht übersetzbaren IPv6-Quelle die reservierte IPv4-Adresse 192.0.0.8 ein und bewahrt die ursprüngliche IPv6-Adresse in einer Erweiterung.

Damit bleibt mehr Diagnosekontext erhalten. Dennoch erklärt der Node-Identification-Entwurf ausdrücklich, dass das Objekt nicht authentifiziert und fälschbar ist. Es dient administrativer Fehlersuche. Ein Datensatz darf „vom Sender behaupteter Kontext“ sagen; „verifizierter Knoten“ braucht unabhängige Grundlage.

Das Objekt bezahlt mit Zitatbytes

RFC 4884 strukturiert ICMP-Erweiterungen und hält vor ihnen mindestens 128 Oktette des Ursprungsdatagramms. RFC 5837 verwendet dieses Format für Schnittstelleninformationen. Die gesamte Fehlermeldung bleibt dennoch an die Next-Hop-MTU gebunden.

Würde das neue Objekt die Grenze sprengen, sollen möglichst viele Bytes aus dem Paketzitat entfernt werden wie nötig – gerundet auf vier Oktette bei ICMPv4 und acht bei ICMPv6. Ist das Zitat bereits am Minimum, darf das Objekt nicht hinzugefügt werden.

Verlorene Bytes können genau die Transportdaten enthalten, mit denen ein Sammler den Fehler einem Fluss zuordnet. Ein besserer Herkunftshinweis kann also schlechtere Korrelation bedeuten. Deshalb braucht die Telemetrie zwei Achsen: Objektinhalt, Bereich und externe Vertrauensbasis einerseits; Zitatlänge, verbleibende Felder und Mehrdeutigkeit andererseits.

Auch das Fehlen ist mehrdeutig. Die Quelladresse kann genügt haben, der Fehlertyp kann unpassend sein, die Funktion kann deaktiviert, aus Geheimhaltungsgründen gesperrt, nicht implementiert oder wegen des Mindestzitats ausgeschlossen sein. Fehlen ist keine negative Identitätsaussage; Vorhandensein keine Beglaubigung.

Implementierungstests und Häufigkeitsdaten liefert das Material nicht. Adoption und reale Verluste müssen später gemessen werden.