Zusammenfassung

  • Revision 05 von draft-ietf-intarea-extended-icmp-nodeid wurde am 7. September 2026 nach einer Prüfung durch den zuständigen Area Director angekündigt. Der Datatracker meldet Last Call Requested, nicht den Abschluss eines Last Call oder eine RFC.
  • Abschnitt 3 verlangt das Objekt, wenn die Antwortadresse den Knoten möglicherweise nicht identifiziert, sofern lokale Richtlinien oder Sicherheitsbelange die Pflicht nicht übersteuern. Abschnitt 5 empfiehlt weiterhin die standardmäßige Deaktivierung – mit einer Ausnahme für IP/ICMP-Übersetzer.
  • Die Sätze regeln verschiedene Ebenen: zuerst den zulässigen Offenlegungsraum, danach das Verhalten für eine dort zugelassene Nachricht. Ein mitgelieferter Name wird dadurch nicht authentisiert.
  • Daniel Kade schlägt eine versionierte Entscheidungstabelle vor, die Konfiguration, Auslöser, Ausnahme, Empfängerklasse, MTU, gesendete und beobachtete Bytes verbindet. Sie ist Analyse, keine IETF-Vorgabe.

Aus einer Empfehlung wurde ein bedingter Zwang

Die Mitteilung vom 7. September bezeichnet die Fassung 05 als Arbeit des Internet Area Working Group. Im Datatracker steht sie als aktiver Internet-Draft, dem IESG zur Veröffentlichung vorgelegt, mit angestrebtem Status Proposed Standard und IESG-Zustand Last Call Requested. Ein Telechat-Termin fehlt. Das ist ein fortgeschrittener Entwurf, noch kein verabschiedeter Standard.

Die normative Änderung geht auf die Prüfung von Éric Vyncke im Oktober 2025 zurück. Der Area Director wollte erklärt haben, unter welchen Umständen vom SHOULD in Abschnitt 3 abgewichen werden dürfe. Zudem fragte er nach der Bedeutung von domain, verlangte klarere Regeln für künftige Bits, grundlegende MTU- und Fragmentierungsregeln und einen ausdrücklichen Antrag auf ein IANA-Untertypenregister.

Der amtliche Vergleich zeigt die Antwort. Fassung 04 empfahl die Erweiterung, wenn sie zur Knotenidentifikation erforderlich war und weder Richtlinie noch Sicherheit Vorrang hatten. Fassung 05 verlangt sie nun, sobald die antwortende IP-Adresse womöglich nicht ausreicht – unter denselben ausdrücklichen Ausnahmen. Außerdem erlaubt sie die bedingungslose Aufnahme und ersetzt die unbestimmte Domänenformulierung durch einen angemessenen Geltungsbereich.

Das MUST macht den Auslöser schärfer, aber die Entscheidung verschwindet nicht. Jemand muss bestimmen, wann eine Adresse genügt, welche Richtlinie eine Ausnahme begründet und wer dafür einstehen kann.

Ein Name im Paket ist kein Geräteausweis

Das Node Identification Object nutzt das Mehrteilformat aus RFC 4884. Es darf ausgewählten ICMPv4- und ICMPv6-Fehlern beigefügt werden und enthält eine IP-Adresse, einen Namen oder beides. Seine Bits lehnen sich an RFC 5837 für Schnittstellen- und Next-Hop-Informationen an, damit Erzeugungs- und Parsercode wiederverwendet werden kann.

Die Adresse soll im passenden Geltungsbereich zur Unterscheidung des Knotens taugen. Eine nur lokal aussagekräftige IPv6-ULA ist ausdrücklich zulässig, wenn der Betreiber der Domäne sie zuordnen kann. Daraus entsteht keine weltweite Attribuierbarkeit.

Das Namensfeld fasst bis zu 63 Nutzoktette in einem gepolsterten Unterobjekt von höchstens 64 Oktetten. Wo passend, soll es sys:hostname aus dem YANG-Systemmodell der RFC 7317 verwenden; ein anderer menschenlesbarer Name ist möglich. Neu ist die Pflicht, bei einer UTF-8-Kürzung keine mehrbyteigen Zeichen zu zerschneiden.

Der Nutzen zeigt sich bei IPv4-Verkehr über IPv6-Nexthops. Ein Zwischenknoten besitzt womöglich keine eindeutige IPv4-Adresse für seine Antwort auf ein IPv4-Traceroute. Ein IP/ICMP-Übersetzer kann die Adresse vor der Übersetzung beifügen und dem Domänenbetreiber eine zusätzliche Zuordnung ermöglichen.

Eine Zuordnung ist keine Authentisierung. Der Entwurf definiert ausdrücklich keinen Authentisierungsmechanismus und warnt, ICMP-Nachrichten samt Inhalt seien leicht zu fälschen. Ein Text, der wie ein Inventarhostname aussieht, bleibt eine Selbstauskunft in einer ungesicherten Nachricht. Er beweist weder Eigentum noch Betreiberrolle, Routenbefugnis oder Störungsverantwortung.

Der Standardwert regelt die Tür, das MUST den Einzelfall

Abschnitt 5 behandelt die Offenlegung. Semantische Knotennamen können interne Informationen verraten; deshalb soll das Hinzufügen konfigurierbar und außerhalb von IP/ICMP-Übersetzern zunächst deaktiviert sein. Zieladressen und ACLs dürfen festlegen, welche Unterobjekte an welche Empfänger gehen.

Abschnitt 3 greift erst für eine Nachricht im freigegebenen Bereich. Reicht die gewöhnliche Antwortadresse womöglich nicht, muss das Objekt folgen, soweit keine lokale Richtlinie oder Sicherheitsentscheidung Vorrang hat. Die erste Ebene entscheidet über die Tür, die zweite über den Verkehr dahinter.

Diese zweistufige Lesart ist eine redaktionelle Analyse und keine formelle IETF-Konformitätsentscheidung. Der Draft definiert ausreichend nicht algorithmisch, benennt keinen organisatorischen Ausnahmeberechtigten und überträgt keinen Grund für das Weglassen. Identische leere Antworten können daher aus verschiedenen, sogar gegensätzlichen Entscheidungen entstehen.

Fehlende Daten haben keinen eingebauten Grund

Empfängt ein Messsystem Time Exceeded ohne Node-ID, weiß es nur, was an diesem Messpunkt ankam. Die normale Quelladresse könnte genügen. Das Gerät könnte am empfohlenen Ausgangszustand stehen. Eine Sicherheitsregel könnte externe Namen sperren, eine ACL sie auf Managementziele begrenzen. Die Software könnte den Entwurf nicht unterstützen oder der Rückweg das Ergebnis verändern.

Für Übersetzer kommt die MTU hinzu. Würde das Objekt die zugrunde liegende MTU sprengen, soll Fassung 05 das zitierte Ursprungsdatagramm innerhalb der Vorgaben aus RFC 4884 kürzen. Reicht auch das nicht, darf der Übersetzer das Objekt nicht hinzufügen. Am Empfänger sieht diese verpflichtende Unterlassung genauso aus wie eine Datenschutzentscheidung.

Auch das Vorhandensein löst die Beweiskette nicht. Das Format verrät nicht, ob der Name tatsächlich aus sys:hostname stammt, aktuell und eindeutig ist oder vom scheinbar bezeichneten Gerät gesendet wurde. Messdaten sollten Selbstauskunft, Inventarabgleich, Betreiberzuordnung und Authentisierungsstatus getrennt halten.

Das IANA-Verzeichnis der ICMP-Parameter führt Klasse 5 bereits als Node Identification Object und verweist noch auf eine ältere individuelle Draft-Fassung. Revision 05 beantragt ein Untertypenregister und unterstellt künftige Bits der Standards Action aus RFC 8126. Die Registrierung kontrolliert die Grammatik; sie bürgt nicht für den Absender eines eingetragenen Wertes.

Eine öffentliche Tabelle braucht keine internen Hostnamen

Eine prüfbare Implementierungstabelle sollte jede Zeile mit der Rolle beginnen: Ursprungsknoten oder Übersetzer. Dazu gehören Adressfamilie, ICMP-Typ, Regel zur Beurteilung der gewöhnlichen Antwortadresse, Konfigurationszustand sowie eine Richtlinien- oder Sicherheitsausnahme mit verantwortlicher Rolle und Version.

Danach folgen Ziel- beziehungsweise ACL-Klasse, erlaubte Unterobjekte und ihr Geltungsbereich. Für das Paket werden MTU-Prüfung, Kürzung des zitierten Datagramms, Grund einer Unterlassung und exakt gesendete Bytes erfasst. Der Empfänger ergänzt Beobachtungspunkt, Zeitpunkt und empfangene Bytes. Authentisierung erhält ein eigenes Feld: in diesem Entwurf nicht vorhanden, sofern kein unabhängiger Mechanismus nachgewiesen ist.

Die öffentliche Fassung kann synthetische Namen, Konfigurations-Hashes und grobe Empfängerklassen verwenden. Nicht die Netzgeheimnisse, sondern die Entscheidungszweige sollen sichtbar werden. So behält der Betreiber die Offenlegungshoheit, der Hersteller kann positive und negative Tests belegen und der Forscher verwechselt ein fehlendes Objekt nicht mit einem eindeutigen Befund.

Quellen