Zusammenfassung
- RFC 768 sendet ein errechnetes Nullergebnis als Einsen; ein Feld aus Nullen bedeutet, dass keine Prüfsumme erzeugt wurde.
- Nicht erkannte Fehler zeigten, wie eine lokale Einsparung den Endpunkten gemeinsame Belege entzog.
- Die IPv6-Ausnahme gilt für benannte Tunnelports und konfigurierte Endpunkte mit zusätzlichen Integritäts-, Pfad- und Sicherheitsaufgaben.
Das Feld durfte die Aussage verweigern
UDP prüft nicht nur Nutzdaten und Header. Ein gedachter IP-Pseudoheader nimmt Quell- und Zieladresse, Protokollnummer und Länge in die Rechnung auf. RFC 768 schützte damit auch vor einer Fehlzustellung.
Einerkomplement-Arithmetik kann regulär Null ergeben; dieses Ergebnis wird als lauter Einsen übertragen. Lauter Nullen sagen etwas anderes: Der Sender hat nicht gerechnet. Das Feld bestätigt nichts, sondern kennzeichnet fehlende Evidenz.
Private Ersparnis schuf einen gemeinsamen blinden Fleck
RFC 1122 ließ Anwendungssteuerung zu, verlangte aber Implementierung von Erzeugung und Prüfung sowie einen eingeschalteten Standard. Es nennt zahlreiche unerkannte Fehler, nachdem LAN-Anwendungen die Prüfung aus Effizienzgründen abgeschaltet hatten.
Die Rechenersparnis fiel beim Sender an. Empfänger und Betreiber verloren eine Möglichkeit, Beschädigung oder Fehlzustellung abzulehnen. Technische Verfügbarkeit war keine Befugnis, für unbekannte Gegenstellen zu entscheiden.
IPv6 stellte ein gemeinsames Mindesturteil her
IPv4 prüfte zumindest seinen eigenen Header. IPv6 besitzt keine Internet-Layer-Prüfsumme. RFC 2460 machte deshalb UDP-Prüfsummen zwingend und verlangte das Verwerfen von Null. Der Transport-Pseudoheader schützte nun Adresskontext, den darunter nichts mehr prüfte.
RFC 8200 behält den Normalfall bei: rechnen, ein Nullergebnis als FFFF eintragen, echte Null verwerfen und den Fehler möglichst protokollieren. Die 16 Bit authentisieren niemanden. Sie verhindern, dass eine Partei minimale Zustellbelege allein aus Bequemlichkeit entfernt.
UDP-Lite erklärte den offenen Bereich
Medienanwendungen können beschädigte Nutzdaten gegenüber vollständigem Verlust bevorzugen. RFC 3828 erlaubt mit UDP-Lite Teilabdeckung, schützt aber immer Pseudoheader und UDP-Lite-Header. Eine übertragene Null ist verboten.
Sender und Empfänger handeln eine erkennbare Grenze aus; der Empfänger setzt seine Mindestabdeckung. Flexibilität entsteht durch begrenzte Zustimmung, nicht durch vollständiges Schweigen.
Die Tunnelausnahme benannte ihre Verantwortlichen
Schnelle Tunnel kapseln teils bereits geschützte innere Pakete, ohne jedes Byte günstig lesen zu können. RFC 6935 erlaubte deshalb Null in eng begrenzten IPv6-Fällen. RFC 6936 definierte die Verantwortung.
Der Modus bleibt standardmäßig aus. Sende- und Empfangsports werden ausgewählt; ein Null akzeptierender Port muss auch berechnete Summen annehmen. Kontrollinformation und Zustand brauchen Schutz, Fragmentierung und Fehlzustellung müssen berücksichtigt, Middleboxes und Pfade geprüft sowie Injection und Überlast begrenzt werden. Normales UDP und UDP-Lite sind zuerst zu erwägen.
Die Ausnahme gehört somit einem identifizierbaren Tunnel, dessen Endpunkte sie konfigurieren, beobachten und zurücknehmen können — nicht jedem Sender im öffentlichen Netz.
Quellen und Grenzen
Die Folge belegen RFC 768, RFC 1122, RFC 2460, RFC 3828, RFC 6935, RFC 6936, RFC 8085 und RFC 8200. Sie zeigen Regeln und dokumentierte Risiken, nicht einheitliche Implementierungen oder globale Fehlerraten. Eine Prüfsumme ist keine kryptografische Authentisierung.
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
