Zusammenfassung

  • RFC 1141 beschrieb eine schnelle Aktualisierung der gespeicherten IP-Prüfsumme, wenn sich nur ein Headerfeld ändert, etwa der TTL-Wert bei der Weiterleitung.
  • RFC 1624 zeigte 1994 eine Grenzbedingung: Die Abkürzung schrieb 0xFFFF, die Neuberechnung 0x0000. Eine korrigierte Gleichung hielt die Bitfolge fest, die zur vollständigen Rechnung passte.

Auf dem Tisch liegen zwei Stempel mit der Aufschrift Null. Einer lässt alle Felder leer, der andere füllt alle aus. Der Buchhalter sieht denselben Betrag; die Maschine sieht verschiedene Bits. Eine solche Doppelbesetzung der Null brachte 1994 eine nützliche Rechenabkürzung für IP-Prüfsummen aus dem Tritt.

RFC 1071 vom September 1988 erklärte die Internet-Prüfsumme mit 16-Bit-Wörtern und Einerkomplementaddition. Das Komplement der Summe wird in den Prüfsummenplatz geschrieben. Wer einen Header kontrolliert, kann den gespeicherten Wert mitaddieren und prüfen, ob das Ergebnis nur aus Einsen besteht. Die Autoren suchten ausdrücklich nach schneller Ausführung: Byte-Reihenfolge, paralleles Addieren, aufgeschobene Überträge und gemeinsame Arbeit mit einer Speicherkopie standen auf der Liste. Auch Änderungen eines einzelnen Felds ließen sich aus der alten Summe ableiten.

Das wichtigste Alltagsbeispiel war der TTL-Wert. Ein Router verringert ihn, die übrigen Teile des IP-Headers bleiben gleich. RFC 1141 vom Januar 1990 brachte die Differenzrechnung in eine Form, die unmittelbar mit der im Paket gespeicherten Prüfsumme arbeitete. Beim Herabsetzen des TTL um eins konnte zum Prüfsummenfeld 0x100 addiert werden, wenn der TTL-Wert im oberen Byte des betroffenen 16-Bit-Worts lag. Das sparte wiederholtes Durchgehen unveränderter Daten.

Der Haken lag im Einerkomplement. Es kennt 0x0000 als positive und 0xFFFF als negative Null. Rechnerisch begegnen sich beide bei null, doch im Header müssen konkrete Bits stehen. RFC 1624 vom Mai 1994 zeigte, dass die Vereinfachung in RFC 1141 eine Distributivregel voraussetzte, die bei einem Ergebnis von null nicht gilt. Eine saubere Zeile Algebra konnte daher das falsche Nullmuster in das Paket setzen.

RFC 1624 legte die Beweisstücke offen. Ein 16-Bit-Feld wechselt von 0x5555 zu 0x3285; alle anderen Headerwörter ergeben zusammen 0xCD7A. Die alte Prüfsumme ist 0xDD2F. Die vollständige neue Berechnung schreibt 0x0000. Mit der Abkürzung aus RFC 1141 entsteht 0xFFFF. Die neue Gleichung HC' = ~(~HC + ~m + m') liefert wieder 0x0000. Bei diesem IP-Header mit mindestens einem nichtleeren Feld könnte die vollständige Berechnung 0xFFFF nicht als gespeicherte Prüfsumme erzeugen.

Welche Folgen hatte das am Empfangsort? Das hing vom Prüfverfahren ab. Wer den gesamten Header einschließlich Prüfsummenfeld addierte und ein Ergebnis aus lauter Einsen verlangte, akzeptierte im Beispiel beide Bitmuster. Wer die Prüfsumme neu berechnete und den Wert mit dem gespeicherten Feld verglich, konnte 0xFFFF ablehnen. Die Differenz im Paket wurde erst durch die konkrete Entscheidung des Empfängers zum sichtbaren Fehler.

Der historische Hinweis in RFC 1624 nannte auch die Fundstelle: Tests an einem Produkt mit dem RFC-1141-Verfahren deckten die Grenzbedingung auf. Eine Simulation bestätigte die verbesserte Rechnung. Der Hersteller und eine Häufigkeit werden nicht genannt. Dafür enthält die öffentliche Aufzeichnung alles, was man für eine technische Korrektur braucht: reproduzierbare Zahlen, die unzutreffende Rechenannahme und eine passende Formel. Eine Variante mit Subtraktion und Übertrag konnte zusätzliche Befehle vermeiden.

Die Abkürzung selbst war weiterhin sinnvoll. Router mussten bei jedem geänderten Headerfeld rechnen, also lohnte sich weniger Arbeit. Die Frage war, ob am Ende dieselben 16 Bits herauskamen wie bei der ganzen Rechnung. Bei zwei Nullen genügt es nicht, bloß „null“ zu sagen.