Zusammenfassung
- Die Internet-Area-Arbeitsgruppe veröffentlichte am 28. September 2026 Version 06 ihres ICMP-Entwurfs zur Identifikation des antwortenden Knotens. Der Text befindet sich in der IESG-Prüfung; er ist weder beschlossene Norm noch RFC.
- Neu ist eine Empfangsregel für die Address Family Identifier (AFI). Wert 1 kennzeichnet eine 32-Bit-IPv4-Adresse, Wert 2 eine 128-Bit-IPv6-Adresse. Bei anderen Werten ist die Länge des Adress-Teilobjekts nicht bestimmbar; die Auswertung des gesamten Node-ID-Objekts muss enden.
- Die ICMP-Nachricht wird dann so behandelt, als fehle dieses Objekt. Wegen der äußeren Längenangaben aus RFC 4884 können spätere Erweiterungen trotzdem weiterverarbeitet werden.
Ein unbekannter Typ verdeckt die nächste Grenze
Für manche Traceroute-Antworten reicht die Quelladresse nicht aus, um den auslösenden Knoten eindeutig zu benennen. Der IETF-Entwurf sieht dafür ein Zusatzobjekt mit Adresse, Namen oder beidem vor. Sein Inhalt ist eine Hilfe für die Fehlersuche und kein kryptografischer Nachweis der Herkunft.
Die Fassung 06 präzisiert den problematischen Fall eines unbekannten AFI. Die Länge des Adressfelds ergibt sich aus der Familie. Fehlt dem Empfänger deren Bedeutung, weiß er nicht, an welcher Stelle ein mögliches Namensfeld beginnt. Wer trotzdem mit einer angenommenen Länge weiterliest, macht aus einer Formatlücke scheinbar gesicherte Knoteninformation. Daher schreibt der Entwurf vor, die Node-ID-Auswertung zu stoppen und dieses Objekt als nicht vorhanden zu behandeln.
Die äußere Struktur ist anders: RFC 4884 definiert Längen für ICMP-Erweiterungen. Dadurch kann eine teilweise verstandene Einheit übersprungen werden, ohne nachfolgende Erweiterungsnachrichten zwangsläufig aufzugeben. Künftige AFI-Ergänzungen nach RFC 5837 sollen auch hier gelten; daraus folgt gerade keine freie Interpretation heute unbekannter Werte.
Der Unterschied zum bisherigen Bericht
In Version 05 fehlte diese explizite Anweisung. Die Security-Directorate-Prüfung fragte nach dem Rest des Objekts, wenn eine unbekannte AFI keine Adresslänge verrät. Laut Änderungsprotokoll reagiert Version 06 auf Prüfungen aus Sicherheits- und Transportbereich. Diese redaktionelle und normative Korrektur belegt keinen Angriff und keinen konkreten Implementierungsfehler.
Daniel Kades frühere Geschichte zur Fassung 05 behandelte, wann eine Knotenkennung gesendet und standardmäßig offengelegt werden sollte. Jetzt geht es um eine andere Instanz der Entscheidung: die Leseberechtigung des Empfängers gegenüber einem Feld, dessen Grenze er nicht kennt.
Quellen
- https://datatracker.ietf.org/doc/draft-ietf-intarea-extended-icmp-nodeid/
- https://www.ietf.org/archive/id/draft-ietf-intarea-extended-icmp-nodeid-06.txt
- https://www.ietf.org/archive/id/draft-ietf-intarea-extended-icmp-nodeid-05.txt
- https://datatracker.ietf.org/doc/review-ietf-intarea-extended-icmp-nodeid-05-secdir-lc-sethi-2026-09-13/
- https://www.rfc-editor.org/rfc/rfc4884.html
- https://www.rfc-editor.org/rfc/rfc5837.html
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

