Zusammenfassung

  • RFC 768 gab der Null im UDP-Prüfsummenfeld zwei verschiedene Bedeutungen: Ein berechnetes Nullergebnis wurde als 0xFFFF übertragen; 0x0000 hieß dagegen, dass keine Prüfsumme erzeugt worden war.
  • Die Host-Anforderungen von 1989 ließen den Verzicht zu, setzten die Berechnung aber als Standard. IPv6 machte die Prüfsumme später verbindlich und erlaubte 2013 mit einer Änderung einen eng begrenzten Tunnel-Fall.

Zwei Nullen in einem Feld

Im August 1980 beschrieb Jon Postels RFC 768 das User Datagram Protocol als Austausch von Datagrammen mit möglichst wenig Protokollmechanik. UDP garantierte weder Reihenfolge noch Schutz vor Duplikaten oder zuverlässige Zustellung. Sein Header war nur acht Oktette lang: Quellport, Zielport, Länge und Prüfsumme, gefolgt von den Nutzdaten.

Das letzte Feld wirkt schlicht, bis die Arithmetik einen Sonderfall erzeugt. UDP verwendet eine 16-Bit-Prüfsumme im Einerkomplement, wie auch TCP. Die Rechnung umfasst den UDP-Header und die Nutzdaten sowie einen Pseudo-Header mit Quell- und Ziel-IP-Adresse, Protokollnummer und UDP-Länge. Postel erklärte, der Pseudo-Header schütze vor fehlgeleiteten Datagrammen.

Im Einerkomplement hat Null zwei Bitmuster: lauter Nullen und lauter Einsen. RFC 768 gab ihnen auf der Leitung unterschiedliche Aufgaben. Ergab die Rechnung null, musste der Sender lauter Einsen übertragen. Ein vollständig auf null gesetztes Feld bedeutete dagegen, dass der Sender keine Prüfsumme erzeugt hatte. Das Format transportierte so neben dem Rechenergebnis einen kleinen Statushinweis, ohne ein zusätzliches Flag-Bit zu benötigen.

Das ist der eng gefasste historische Punkt dieses Artikels. Eine UDP-Prüfsumme von null war keine berechnete Prüfsumme mit dem Ergebnis null. Sie codierte das Fehlen einer Berechnung. Wer beides verwechselte, konnte ein gültiges Datagramm verwerfen oder fehlende Fehlererkennung als abgeschlossene Prüfung behandeln.

Optional hieß nicht Standard

Die ursprüngliche Spezifikation ließ das Weglassen der Prüfsumme etwa zu Debugging-Zwecken oder wenn ein Protokoll höherer Ebene sie nicht benötigte zu. Neun Jahre später präzisierte RFC 1122 die Betriebsregel für Internet-Hosts. Ein Host musste die Erzeugung und Prüfung der UDP-Prüfsumme unterstützen. Eine Anwendung durfte die Erzeugung steuern, aber sie musste standardmäßig eingeschaltet sein. Empfänger durften wählen, ob sie Datagramme ohne Prüfsumme an Anwendungen weitergaben.

RFC 1122 benannte auch einen verbreiteten Implementierungsfehler: Ein berechnetes Nullergebnis muss als 65535 übertragen werden; das vollständig auf null gesetzte Feld heißt „nicht vorhanden“. Das Dokument berichtete, einige nur in lokalen Netzen eingesetzte Anwendungen hätten Prüfsummen aus Effizienzgründen abgeschaltet, und zahlreiche unentdeckte Fehler seien gemeldet worden. Zahlen, konkrete Vorfälle oder einen Nenner nannte es nicht. Der Abschnitt belegt eine von Standardautoren festgehaltene Sorge, aber keine Messung ihrer Verbreitung.

Eine Prüfsumme war nie eine Signatur. Der Pseudo-Header konnte bestimmte Fehlzustellungen erkennen, die Rechnung einen Teil zufälliger Beschädigungen. Sie authentifizierte weder den Absender noch verhinderte sie absichtliche Änderungen oder bewies, dass Anwendungsdaten sinnvoll waren. „Prüfsumme vorhanden“ und „Paket vertrauenswürdig“ waren verschiedene Aussagen.

IPv6 zog die Grenze enger

Die IPv6-Spezifikation von 1998, RFC 2460, machte die UDP-Prüfsumme verpflichtend. Ergab die Berechnung null, musste auch dieser Wert als 0xFFFF geschrieben werden; ein Empfänger sollte ein IPv6-UDP-Datagramm mit Prüfsummenfeld null verwerfen. Damit war die frühere optionale Kennzeichnung des Verzichts im normalen IPv6-UDP-Verkehr unzulässig.

Später entstand ein konkreter Leistungsfall. RFC 6935 und RFC 6936 änderten 2013 die IPv6-Prüfsummenverarbeitung für bestimmte UDP-Tunnel. Die Tunnel konnten Pakete transportieren, die bereits eigene Integritätsprüfungen hatten; die Berechnung einer äußeren Prüfsumme kostete zusätzliche Arbeit. Die Ausnahme hing von Anwendbarkeitsbedingungen, dem Verhalten beider Endpunkte und der Kompatibilität von Zwischenstationen ab. Sie machte die Null-Prüfsumme nicht zu einer allgemeinen IPv6-Option.

Der Ablauf der Standards zeigt: Das Bitmuster blieb gleich, doch sein erlaubter Kontext änderte sich. Bei IPv4 durfte null den Verzicht markieren, während Host-Anforderungen die Berechnung standardmäßig einschalteten. IPv6 lehnte den Verzicht zunächst ab und ließ ihn später unter Bedingungen für eine bestimmte äußere Tunnel-Kapselung wieder zu. Der Zahlenwert allein sagte dem Empfänger nie, ob der Verzicht zulässig war. IP-Version und Einsatzzweck gehörten dazu.

Quellen