Zusammenfassung

  • Revision 05 schlägt für bestimmte ICMP-Fehler eine zusätzliche IP-Adresse, einen Knotennamen oder beides vor, wenn die normale Antwortadresse das System nicht ausreichend identifiziert.
  • Der IETF Last Call endete am 22. September 2026; das Dokument bleibt jedoch ein Internet-Draft in IESG-Prüfung und ist weder ein verabschiedeter RFC noch ein Implementierungsnachweis.
  • Die Funktion soll grundsätzlich standardmäßig abgeschaltet sein, weil Namen Topologie verraten können; ein Authentisierungsverfahren gehört nicht zum Entwurf.

Der Bildschirm verspricht mehr Eindeutigkeit als das Paket

Ein klassischer Traceroute-Auszug ordnet jeder Zeile eine Adresse zu. Daraus entsteht leicht die Annahme, jede Adresse stehe für genau einen Router. In Netzen mit gemeinsam genutzten IPv4-Antwortadressen oder einem IPv6-only-Forwarding-Kern ist diese Zuordnung nicht zwingend. Die Antwort belegt einen beobachteten Hop, nicht automatisch den konkreten Knoten.

Der Entwurf zur Knotenidentifikation ergänzt die ICMP-Antwort um ein separates Objekt. Es kann eine IPv4- oder IPv6-Adresse passenden Geltungsbereichs, einen menschlich lesbaren Namen mit höchstens 63 Nutzoktetten oder beide Angaben enthalten.

Damit entstehen zwei Belege: die äußere Absenderadresse des zurückkommenden Fehlers und die im Objekt behauptete Herkunft. Ein Diagnosesystem sollte sie verknüpfen, aber nicht zu einer einzigen beglaubigten Identität verschmelzen.

Nach dem Last Call folgt weiterhin Prüfung

Das IESG eröffnete den Last Call am 8. September und setzte den 22. September als Frist. Der Datatracker-Schnappschuss vom 24. September führt Revision 05 zugleich als Active, Submitted to IESG for Publication, Waiting for AD Go-Ahead und IANA OK - Actions Needed. Die öffentliche Seite nennt außerdem den IESG-Telechat vom 8. Oktober.

Diese Angaben markieren Verfahrensschritte. Sie sind keine Freigabe. Das Dokument nennt sich weiterhin Internet-Draft und läuft am 11. März 2027 aus. Der Telechat kann eine Zustimmung, Überarbeitung oder weitere Prüfung auslösen. Selbst ein künftiger Proposed Standard würde weder Produktcode noch Aktivierung oder beobachteten Nutzen nachweisen.

Im IANA-Register für ICMP-Parameter ist Class Value 5 bereits als Node Identification Object eingetragen; der Verweis führt zu einem älteren individuellen Entwurf. Der Eintrag koordiniert eine Zahl. Er entscheidet nicht über Revision 05 und bestätigt keinen empfangenen Namen.

Was das Objekt transportiert

Die Konstruktion nutzt den Erweiterungsrahmen aus RFC 4884. Zulässig ist sie für ICMPv4 Time Exceeded, Destination Unreachable und Parameter Problem sowie für ICMPv6 Time Exceeded und Destination Unreachable.

Eine Adresse darf lokal bedeutsam sein, sofern der Betreiber des Bereichs sie auswerten kann. Als Name kann sys:hostname aus YANG oder eine andere sinnvolle Bezeichnung dienen. Reihenfolge, Länge, Padding und Kürzung sorgen für parsebare Bytes. Sie sagen nicht, wer den Wert eingetragen hat.

RFC 5837 identifiziert Schnittstellen und nächste Hops. Der neue Entwurf zielt auf den Ursprungs­knoten des Fehlers. Eingangsinterface, Ausgangsinterface, Next Hop und Knoten sind getrennte Beobachtungsobjekte.

Der Bedarf ergibt sich unter anderem aus IPv4-Routen mit IPv6 Next Hop und aus dem XLAT-Vorschlag mit Dummy-IPv4-Adresse. RFC 7915 und RFC 6877 beschreiben Übersetzung und 464XLAT, aber keine Verbreitung des neuen Objekts.

Aussagekraft und Offenlegung sind dieselbe Eigenschaft

Ein Name kann Standort, Rolle und Ebene eines Geräts zeigen. Genau diese Semantik hilft intern und verrät extern Struktur. Revision 05 macht die Ausgabe daher konfigurierbar und empfiehlt sie außerhalb des beschriebenen Übersetzerfalls standardmäßig abzuschalten. Zielabhängige Auswahl und ACLs sollen den Empfängerkreis begrenzen.

Die Policy braucht feinere Klassen als „ein“ und „aus“. Ein internes Messsystem kann Name und Adresse erhalten; eine Kundendiagnose vielleicht nur eine eingeschränkte Adresse; ein beliebiger Internet-Host möglicherweise gar keine Zusatzinformation. Eine ULA kann im eigenen Netz präzise und außerhalb bedeutungslos sein. Kürzung kann den Teil entfernen, der zwei Namen unterscheidet.

Parsebar heißt nicht echt

Der Sicherheitsabschnitt stellt klar, dass der Entwurf keine Authentisierung definiert und ICMP-Inhalte leicht gefälscht werden können. Die Prüfsumme von RFC 4884 schützt die Struktur vor bestimmten Fehlern, nicht die Identität des Erzeugers.

Eine Untersuchung sollte deshalb Rohpaket, Zeitpunkt, Messpunkt, ursprüngliche Probe, äußere Quelladresse, Subobjekte, erwartete Offenlegungsregel und Softwarestand aufbewahren. Authentisierte Management-Telemetrie, Konfiguration und wiederholte Messungen können den Befund stützen, bleiben aber eigene Belege.

Running-Code Primacy verlangt Prüfung am wirksamen System. Minimum Initial Specification and Localized Future Decision trennt gemeinsames Format von lokaler Offenlegung. Reality Layers and Symbolic Power verhindert, dass Registereintrag und korrektes Paket die Ebenen Implementierung, Echtheit und Ergebnis ersetzen.

Quellen