Zusammenfassung

  • IPv4 Parameter Problem verwarf das nicht weiter verarbeitbare Datagramm, konnte aber mit einem acht Bit breiten Pointer das fehlerhafte Oktett im Header benennen.
  • ICMPv6 erweiterte den Pointer auf 32 Bit und unterschied fehlerhaftes Feld, unbekannten Next Header und unbekannte Option entlang einer Extension-Header-Kette.
  • Ein Pointer darf hinter das Ende der zurückgesandten Paketkopie zeigen. Seine Genauigkeit beweist weder Authentizität noch Ursache und gestattet keinen Zugriff außerhalb des empfangenen Puffers.

Nicht nur verloren, sondern an einer Stelle abgelehnt

RFC 792 beschrieb 1981 einen IPv4-Header, dessen Parameter einen Host oder ein Gateway am Weiterverarbeiten hinderten. Das Datagramm musste verworfen werden. War genau dieser Fehler der Grund, durfte der Knoten ICMP Typ 12, Parameter Problem, an die Quelle senden.

Code 0 machte den acht Bit breiten Pointer gültig. Sein Wert bezeichnete das Oktett im ursprünglichen IPv4-Header, an dem der Fehler festgestellt worden war. Offset 1 konnte auf Type of Service zeigen; bei vorhandenen Optionen konnte 20 den Typ der ersten Option markieren. Selbst eine Position mitten in einer Option war möglich.

Damit bekam Ablehnung eine Koordinate. Die Quelle konnte den Offset mit ihrem Serializer, ihrer Konfiguration oder einem aufgezeichneten Paket vergleichen. Der meldende Knoten behielt die Entscheidung über den Drop. Die Quelle behielt die Verantwortung, ihre eigenen Bytes zu prüfen.

Zusätzlich enthielt die Antwort den Internet Header und die ersten 64 Datenbits. Acht Oktette reichten bei frühen TCP- oder UDP-Paketen häufig aus, um Ports und damit einen Prozess zuzuordnen. Das Zitat stellte Zusammenhang her; der Pointer lokalisierte die erkannte Unstimmigkeit.

ICMP versprach dennoch keine lückenlose Rückmeldung. RFC 792 bezeichnete die Nachrichten als Feedback über Probleme, nicht als Zuverlässigkeitsdienst. Ein fehlender Parameter Problem konnte Drop, Filterung, Rate Limit oder Verlust der Fehlermeldung bedeuten.

Diagnose wird Hostpflicht, aber kein Freibrief

RFC 1122 nahm Parameter Problem 1989 in die Pflichten eines Hosts auf. Lässt sich der verursachende Prozess bestimmen, soll die Information nach oben gelangen. Für TCP ist der Fehler zu melden, nicht ohne weiteren Kontext als zwingender Abbruchbefehl zu behandeln. Die Schicht mit dem relevanten Zustand entscheidet über die Reaktion.

Der Host-Standard verband Diagnose mit Ressourcenverantwortung. Auffällige Header zu protokollieren hilft in einer heterogenen Umgebung. Harmlose Anomalien dürfen aber weder Speicher noch Rechenzeit aufzehren. Gute Fehlerauskunft ist deshalb immer auch eine Aussage darüber, wie viel Aufwand ein fremdes fehlerhaftes Paket auslösen darf.

RFC 1812 konkretisierte 1995 die IPv4-Routerprüfung. Ungültige Datagramme werden verworfen und gewöhnlich protokolliert. Sind genügend Headerteile sicher lesbar, kann ein Router auf Internet Header Length oder Total Length zeigen. Derselbe Prüfpunkt kann jedoch durch Link-Trunkierung, Beschädigung, eine andere IP-Version oder fehlerhafte Erzeugung an der Quelle scheitern. Der Offset ist keine vollständige Ursachenanalyse.

Das zurückgesandte Zitat durfte nun so groß sein, wie es ohne Überschreiten des minimalen IPv4-Reassembly-Puffers von 576 Byte möglich war. Mehr Kontext blieb mit einer klaren Verstärkungsgrenze verbunden.

IPv6 verlängerte den Koordinatenraum

Ein IPv4-Header ist einschließlich Optionen höchstens 60 Byte lang; acht Bit genügen. IPv6 besitzt einen festen 40-Byte-Basisheader, dem eine geordnete Kette von Extension Headers folgen kann. Jeder Next Header bestimmt den nächsten Verarbeitungsschritt. Ein Problem kann weit hinter dem Anfang liegen.

RFC 2463 definierte 1998 ICMPv6 Parameter Problem als Typ 4 mit einem 32-Bit-Pointer. Der Wert ist ein Oktett-Offset innerhalb des auslösenden Pakets. Code 0 steht für ein fehlerhaftes Headerfeld, Code 1 für einen unbekannten Next Header und Code 2 für eine unbekannte IPv6-Option. RFC 4443 übernahm die Struktur 2006.

Code 1 mit Pointer 40 bedeutet, dass der Wert unmittelbar nach dem Basisheader nicht erkannt wurde. Vierzig ist keine Hop-Anzahl und keine Schwereklasse, sondern eine Position vom Paketanfang.

RFC 8200 bindet diese Position an die Verarbeitungsreihenfolge. Ein Ziel darf einen unbekannten Übergang nicht überspringen, um dahinter einen vertrauten Header zu suchen. Muss es fortfahren und kennt den aktuellen Next Header nicht, verwirft es und zeigt auf dessen Feld. Unbekannte Optionen können Code 2 auslösen; die Aktionsbits des Option Type bilden jedoch einen eigenständigen Mechanismus.

Der Pointer kennzeichnet somit die Grenze dieses Parsers. Über spätere Header sagt er nichts. Der erste gemeldete Stopp ist kein Gütesiegel für den Rest.

Der Offset kann weiter reichen als das Zitat

ICMPv6-Fehler sollen so viel wie möglich vom auslösenden Paket enthalten, ohne dass die Antwort die minimale IPv6-MTU überschreitet. Bei einer langen Extension-Kette kann das fehlerhafte Feld außerhalb des zurückgesandten Abschnitts liegen.

RFC 4443 bewahrt in diesem Fall den tatsächlichen Offset. Der Pointer darf hinter das Ende der im ICMPv6-Paket enthaltenen Ursprungsbytes zeigen. Die Quelle erfährt: Der Melder stoppte bei N. Sie erhält aber nicht zwangsläufig das Byte an N.

Das ist eine wichtige Form ehrlicher Unvollständigkeit. Würde der Pointer auf das letzte vorhandene Byte gekürzt, träfe die Beschuldigung das falsche Feld. Würde die Antwort unbegrenzt wachsen, würde Diagnose zur Amplifikation. Der Standard erhält die genaue Ortsangabe und macht zugleich den fehlenden Inhalt sichtbar.

Software darf den Pointer deshalb nicht ungeprüft als Array-Index verwenden. Ein gültiger Offset im Koordinatenraum des vollständigen Pakets liegt möglicherweise außerhalb des lokalen Puffers. RFC 8883 verlangt ausdrücklich eine Längenprüfung vor dem Lesen.

Ein kurzes Zitat kann außerdem enden, bevor der Upper-Layer-Typ erkennbar wird. Dann lässt sich kein Prozess auswählen, und die Fehlermeldung kann nach der IPv6-Verarbeitung verworfen werden. Präzise Netzwerkschichtdaten garantieren keine Zustellung an die Anwendung.

Ein korrektes Format kann an einer lokalen Grenze enden

RFC 8883 ergänzte 2020 Codes 5 bis 10. Sie melden einen unbekannten Next Header an einem Zwischenknoten sowie Grenzen für Größe eines Extension Headers, Gesamtlänge der Kette, Zahl der Header, Zahl der Optionen oder Größe einer Option. Je nach Code zeigt der Pointer auf den unbekannten Wert, das erste Oktett jenseits des Limits oder das erste zu viel gezählte Element.

Das Paket muss dabei syntaktisch nicht fehlerhaft sein. Es kann korrekt aufgebaut sein und mehr Analyse verlangen, als ein bestimmter Knoten bereitstellt. Code und Offset beschreiben dann eine lokale Verarbeitungskapazität.

So wird ein Implementierungslimit nicht als universelle Ungültigkeit ausgegeben. Ein anderer Knoten kann dieselbe Kette akzeptieren. Umgekehrt verpflichtet eine zulässige Form nicht jeden Router zu unbegrenzten Parserressourcen. Entscheidend ist, dass die Grenze beobachtbar und ihrem Melder zugeordnet bleibt.

Eine genaue Meldung kann trotzdem täuschen

Gewöhnliche ICMP-Fehler sind standardmäßig nicht authentisiert. RFC 4443 behandelt gefälschte Quellen, veränderte Felder, Denial of Service und manipulierte Reaktionen höherer Schichten. Vor einer Zustandsänderung muss die Quelle Adressen, Protokoll, Ports und tatsächlich gesendeten Verkehr korrelieren.

ICMPv6-Fehler müssen zudem rate-limitiert werden. Ein Strom fehlerhafter Pakete darf keinen endlosen Antwortstrom erzwingen. Multicastregeln, Filter und normaler Verlust erzeugen weiteres Schweigen. Eine empfangene Meldung belegt, dass ein Melder sie erzeugt hat; ihr Ausbleiben belegt keine erfolgreiche Verarbeitung überall.

Parameter Problem standardisierte deshalb keine allwissende Diagnose, sondern vier getrennte Tatsachen: Drop, gewählte Ursachenklasse, erkannte Position und begrenzter Kontext. Der Wert des Pointers liegt gerade darin, dass seine Präzision diese Grenzen nicht verschweigt.

Quellen