Zusammenfassung

  • IPv4 prüfte nur seinen veränderlichen Header. Ein Router konnte den Eingang prüfen, TTL oder andere zulässige Felder ändern und danach eine neue Prüfsumme für den neuen Zustand erzeugen, ohne Nutzdaten zu garantieren.
  • TCP und UDP nahmen Transportheader, Daten und einen Pseudoheader mit ausgewählten IP-Fakten in die Rechnung auf. Das half gegen Fehlzustellung, war aber weder Absenderauthentisierung noch Eigentums- oder Pfadnachweis.
  • Einerkomplement-Arithmetik kennt positive und negative Null. RFC 1141 konnte 0xFFFF liefern, obwohl vollständige Neuberechnung 0x0000 ergab; RFC 1624 korrigierte diese Grenze. IPv6 entfernte die Prüfsumme aus dem Basisheader, nicht die Integritätsverantwortung höherer Schichten.

Ein Header, der unterwegs erneuert wurde

IPv4s Time to Live wird an jedem Verarbeitungspunkt um mindestens eins verringert. Fragmentierung verändert Länge, Flags und Offset; auch zulässige Optionen können den Header ändern. Der Router leitet deshalb nicht immer genau den Header weiter, den er empfangen hat.

RFC 791 definiert die Header Checksum als Einerkomplement der Einerkomplement-Summe aller 16-Bit-Wörter im Header. Das Prüfsummenfeld gilt während der Berechnung als null. Ausdrücklich erfasst wird nur der Header.

Ein Router prüft die eingehende Fassung, verwirft einen Fehler, nimmt seine legitime Änderung vor und hinterlässt einen passenden neuen Wert. Die Prüfsumme ist kein unverändertes Siegel des Ursprungs. Sie ist eine lokale Aussage über eine bestimmte Headerfassung bis zum nächsten Verarbeitungspunkt.

RFC 791 grenzt sie weiter ein: IP bietet hier weder Fehlerkontrolle für Daten noch Bestätigungen oder Wiederholungen. Ein gültiger IPv4-Header sagt nichts über die Unversehrtheit der Nutzlast. Geschützt werden die Informationen, auf deren Grundlage die Internetschicht handelt.

Gleiches Rechnen, verschiedene Reichweiten

IPv4 summiert den eigenen Header. RFC 768 lässt UDP seinen Header, die Daten und einen Pseudoheader erfassen. RFC 793 erfasst TCP-Header und Text sowie einen 96-Bit-Pseudoheader.

Damit zwingt eine TTL-Änderung keinen Router, eine Ende-zu-Ende-Transportprüfsumme anzufassen. Der Router erneuert IPv4; die Endpunkte verantworten TCP oder UDP. Eine Sicherungsschicht kann zusätzlich einen Frame prüfen, doch diese Aussage endet an einem Link.

Mehrere bestandene Prüfungen verschmelzen nicht zu einem universellen Zertifikat. Jede hat eigenes Material, einen eigenen Erzeuger und eine eigene Lebensdauer.

Der nicht übertragene Pseudoheader

UDP bezieht Quelladresse, Zieladresse, Protokollnummer und UDP-Länge ein; TCP verwendet Quelle, Ziel, Protokollnummer und TCP-Länge. Dieser Pseudoheader wird nicht als gesonderte Struktur übertragen. Der Empfänger rekonstruiert ihn aus den IP-Angaben.

RFC 768 und RFC 793 nennen Schutz vor fehlgeleiteten Datagrammen und Segmenten als Zweck. Unveränderte TCP-Bytes sollen nicht beiläufig gültig erscheinen, wenn sie unter einem anderen Ziel oder Protokoll ankommen.

Eine Authentisierung ist das nicht. Wer ein Paket erzeugen oder bewusst verändern kann, kann die Summe neu bilden. Der Pseudoheader beweist weder Adressinhaberschaft noch Registerrichtigkeit, Routingrecht oder einen unbeobachteten Pfad. Er bindet nur abhängige Felder an eine billige Konsistenzprüfung.

Warum UDP beide Nullen brauchte

Im Einerkomplement steht 0x0000 für positive Null und 0xFFFF für negative Null. RFC 768 gibt beiden Bitmustern unterschiedliche Protokollbedeutung: Ergibt die UDP-Berechnung null, wird alles eins übertragen. Ein übertragenes Alles-null-Feld bedeutet, dass der Absender keine Prüfsumme erzeugte.

0xFFFF kann somit ein gültiges Rechenergebnis darstellen, 0x0000 unter IPv4 die ausgelassene Prüfung. Die Kodierung trennt „gerechnet, Ergebnis null“ von „nicht gerechnet“.

RFC 8200 macht UDP-Prüfsummen unter IPv6 standardmäßig verpflichtend. Null wird als 0xFFFF geschrieben; Alles-null muss verworfen werden. Eine begrenzte Ausnahme gilt für bestimmte UDP-Tunnel unter zusätzlichen Bedingungen, nicht als allgemeine Freistellung.

Freiheit bei der schnellen Implementierung

RFC 1071 beschreibt Eigenschaften, die verschiedene Maschinen ausnutzen konnten. Bleibt die gerade oder ungerade Byteposition erhalten, ist die Summe kommutativ und assoziativ. Puffer lassen sich teilen, Teilsummen später verbinden. Beide Byteordnungen, breitere Akkumulatoren, entrollte Schleifen und parallele Arbeit sind möglich. Ein einzelnes Schlussbyte wird nur für die Berechnung mit null ergänzt.

Der gemeinsame Vertrag schreibt also Ergebnis und Abdeckung vor, nicht eine universelle Schleife. Lokale Optimierung endet dort, wo Bytepaarung, End-around Carry oder Schlussbyte ein anderes Bitmuster erzeugen.

Kleine Änderung, kleine Rechnung

Beim Herabsetzen der TTL kennt der Router das veränderte 16-Bit-Wort. RFC 1141 zeigt, wie der alte Beitrag entfernt und der neue addiert wird, ohne den gesamten Header zu summieren. Eine TTL-Verringerung um eins entspricht je nach Byteposition einer Addition von 1 oder 256 zum gespeicherten Feld in Einerkomplement-Arithmetik.

RFC 1624 nennt außerdem Fragmentierung und Source-Route-Änderung. Der Aufwand folgt der Mutation. Doch korrekt ist die Abkürzung nur, wenn sie für jeden Grenzfall dieselbe Ausgabe wie vollständige Neuberechnung liefert.

Als eine Formel in die falsche Null fiel

RFC 1624 dokumentiert eine Lücke: RFC 1141 nutzte implizit eine distributive Umformung, die bei einem Nullergebnis im Einerkomplement nicht gilt. Im Beispiel ändert sich ein Wort von 0x5555 zu 0x3285, die übrigen Headeroktette summieren sich zu 0xCD7A. Vollständige Berechnung ergibt 0x0000; die ältere Aktualisierung 0xFFFF.

Für einen IPv4-Header sind diese Darstellungen nicht beliebig. Mindestens ein Feld ist ungleich null. Die Addition nichtnulliger Eingaben kann negative, aber nicht positive Null ergeben; nach dem abschließenden Komplement kann das Prüfsummenfeld 0x0000, nicht aber kanonisch 0xFFFF enthalten.

Die korrigierte Gleichung lautet HC' = ~(~HC + ~m + m'), mit Einerkomplement-Addition in jedem Schritt. Sie vermeidet die ungültige Verteilung und stimmt mit der Referenzberechnung überein.

Manche Empfänger summierten das empfangene Feld mit und verglichen das Ergebnis gemäß RFC 1071 mit negativer Null. Sie konnten im Beispiel beide Darstellungen akzeptieren. Andere berechneten neu und verglichen unmittelbar mit dem Feld. Produkttests machten den Fehler sichtbar; Analyse und Simulation bestätigten die Korrektur.

Toleranz beim Empfänger entbindet den Erzeuger nicht von kanonischer Ausgabe. Interoperabilität darf nicht davon abhängen, dass der nächste Implementierer einen unmöglichen Wert großzügig deutet.

IPv6 verlagerte die Grenze

Der IPv6-Basisheader in RFC 8200 enthält keine Internet-Prüfsumme. TCP, UDP und ICMPv6 verwenden jedoch einen IPv6-Pseudoheader mit 128-Bit-Quell- und endgültiger Zieladresse, Oberlängenangabe und Next Header.

Bei ICMPv6 erklärt RFC 8200 ausdrücklich, dass abhängige IPv6-Felder anders als bei IPv4 nicht mehr von einer Internetschicht-Prüfsumme erfasst sind. Verantwortung verschwand nicht; sie wanderte zu den Protokollen, die diese Felder benötigen.

IPv4 ließ jeden Router eine kleine Headeraussage prüfen und erneuern, häufig neben Link- und Transportkontrollen. IPv6 entfernte diese Wiederholung aus dem festen Header, behielt Endpunktprüfungen und schloss die allgemeine UDP-Auslassung.

Quellen und Unsicherheiten

RFC 768 trägt UDP und die Nullkodierung, RFC 791 IPv4, RFC 793 TCP, RFC 1071 die Recheneigenschaften, RFC 1141 die Aktualisierung, RFC 1624 die Korrektur und RFC 8200 die IPv6-Grenze.

Sie belegen weder einen Alleinerfinder noch heutige Hardware-Offload-Verbreitung, universelle Herstellerdefaults oder eine bestimmte Restfehlerrate. Bestehen schließt absichtliche Änderung mit Neuberechnung nicht aus; Scheitern identifiziert allein kein Gerät und keine Person.

Gesichert ist die engere Geschichte: Exakte Abdeckung, Erzeugerrolle und Ablaufgrenze machten viele Inkonsistenzen billig sichtbar, ohne aus einer Summe allgemeine Autorität zu schaffen.