Zusammenfassung

  • RFC 894 setzte den EtherType für IPv4 auf hexadezimal 0800 und verlangte Null-Padding, wenn das Ethernet-Datenfeld sonst unter 46 Oktetten geblieben wäre. Die zusätzlichen Bytes gehörten weder zum IP-Paket noch zum IPv4-Feld Total Length.
  • Ein Empfänger brauchte zwei Längen zugleich: Speicher für die tatsächlich gelieferte Link-Nutzlast und Total Length als Ende der IP-Auswertung. RFC 6274 formulierte die Schachtelung später ausdrücklich und verlangte Verwerfen, wenn der Link weniger lieferte, als IP behauptete.
  • Semantisch fremde Bytes blieben physisch sichtbar. CERT/CC dokumentierte Treiber, die alte Pufferinhalte als Padding übertrugen; die verifizierten Errata zu RFC 894 zeigen eine parallele Trennung zwischen unverändertem Veröffentlichungstext und überprüfter Korrektur.

Drei Grenzen statt einer Paketlänge

RFC 791 definiert Total Length als Länge des gesamten IPv4-Datagramms einschließlich IP-Header und Daten. IHL misst dagegen den Header in 32-Bit-Wörtern. Die erste Grenze liegt daher nach dem Header, die zweite nach dem Datagramm.

Mit RFC 894 kam eine äußere Grenze hinzu. Auf dem 10-Mb/s-Ethernet mit 48-Bit-Adressen musste das Datenfeld mindestens 46 Oktette und durfte gewöhnlich höchstens 1500 umfassen. Dazwischen lag das IP-Datagramm.

Ein minimaler IPv4-Header ohne Nutzdaten ist zwanzig Oktette lang. Damit Ethernet auf 46 kommt, fehlen 26. Der Sender füllt sie mit Null-Oktetten, ändert Total Length aber nicht. Eine Änderung würde der unteren Schicht erlauben, Daten zu erfinden, die IP nie erhalten hat.

Die korrekte Beziehung lautet deshalb:

IHL × 4 <= IP Total Length <= empfangene Link-Nutzlast

Die rechte Ungleichung darf streng sein. Genau dort befindet sich legitimes Link-Padding.

0800 war ein Typ, keine Größenangabe

RFC 894 verlangte im Ethernet-Type-Feld den hexadezimalen Wert 0800. Im Datenfeld folgte unmittelbar der IP-Header, danach die IP-Daten. 0800 entspricht dezimal 2048, beschreibt jedoch keine Nutzlast von 2048 Oktetten.

Die Unterscheidung wurde wichtig, als Ethernet- und IEEE-802.3-Frames auf demselben Kabel vorkamen. RFC 1122 erklärte, dass das überlappende Zwei-Oktett-Feld bei Werten bis 1500 eine 802.3-Länge, bei gültigen Werten über 1500 einen EtherType darstellt.

2048 wählt also die IPv4-Grammatik. Erst innerhalb dieser Grammatik bestimmt Total Length das Ende. Wer stattdessen bis zum Ende des Link-Puffers weiterliest, macht aus äußerem Material fälschlich IP-Inhalt.

RFC 1122 verpflichtete Ethernet-Hosts, RFC-894-Frames zu senden und zu empfangen. Die IEEE-802-Form aus RFC 1042 sollte empfangen und durfte gesendet werden. Wer beide senden konnte, brauchte einen Konfigurationsschalter mit RFC 894 als Voreinstellung. Gemeinsames Kupfer war kein Beweis für ein gemeinsames Format.

Acht Oktette außen änderten die Kapazität, nicht die Bedeutung

RFC 1042 setzte zwischen MAC und IP die IEEE-802.2-LLC- und SNAP-Header. Zusammen beanspruchten sie acht Oktette. Die letzten 16 SNAP-Bits trugen wieder EtherType: 2048 für IP, 2054 für ARP.

Auch dort sollte eine Mindestgrößenanforderung mit Nullen erfüllt werden, die außerhalb von IP Total Length blieben. Die im Dokument genannten 28 Oktette Mindestgröße setzen sich aus zwanzig Oktetten IPv4-Header und acht Oktetten LLC/SNAP zusammen, ohne MAC-Header. Sie ersetzen nicht die 46 Oktette des RFC-894-Ethernet-Datenfelds.

RFC 1122 nannte 1500 als Ethernet-MTU und 1492 als 802.3-MTU. Die acht äußeren Oktette erklären die Differenz. Sie werden weder vom IP-Header abgezogen noch als IP-Padding hinzugezählt.

Der zeitgleiche RFC 895 liefert eine zweite Kontrolle. Das Experimental Ethernet mit 3 Mb/s, Acht-Bit-Adressen und anderem Type-Wert erlaubte ein 1536-Oktett-Datagramm. Dennoch blieb auch dort Padding für die Link-Mindestgröße außerhalb von Total Length. Die lokalen Zahlen wechselten, die Schichtgrenze nicht.

Das falsche Minimum blieb im Dokument

Im veröffentlichten RFC 894 steht nach der korrekten Mindestgröße 46 eine widersprüchliche Zeile: Das Datenfeld habe ein „minimum“ von 1500 Oktetten, daher betrage das maximale IP-Datagramm 1500. Technisch muss das erste Wort „maximum“ heißen.

Das verifizierte technische Erratum 570, 2001 gemeldet, hält genau diese Korrektur fest. Erratum 5141, 2017 gemeldet und 2024 verifiziert, dokumentiert sie erneut. Das Verifikationsjahr ist keine Änderung der Ethernet-Physik.

Die Errata-Regel des RFC Editor erhält die Beweisrollen getrennt. Veröffentlichte RFCs ändern sich nicht. Verifizierte Errata gelten als korrekt, werden aber nicht in TXT, PDF oder XML eingearbeitet.

Der Originaltext belegt die Veröffentlichung, das Erratum die geprüfte Lesart. Eine still korrigierte Kopie verbessert den Satz und verliert die Herkunft. Eine wörtliche Befolgung des Fehlers erhält die Herkunft und verliert die Technik. Nur die verknüpfte Doppelspur erhält beides.

Trailer und Padding teilen keinen Vertrag

RFC 893 beschrieb ebenfalls eine Anordnung am Paketende. Bei Trailer Encapsulation wanderten variable höhere Header hinter die Daten, um bestimmten Empfängern Speicher-Ausrichtung und weniger Kopien zu ermöglichen. Der Link-Nachbar musste die alternative Darstellung verstehen.

RFC-894-Padding verschob keinen Header. IP-Header und IP-Daten blieben in normaler Reihenfolge; Nullen folgten erst nach dem durch Total Length markierten Ende. Der Empfänger musste nichts rekonstruieren, sondern die IP-Auswertung rechtzeitig beenden.

Padding ist damit weder Trailer noch IP-Option noch Frame Check Sequence. Die räumliche Nähe zum Ende verleiht den Elementen keine gemeinsame Autorität.

Speichergröße und Parsergrenze beantworteten verschiedene Fragen

RFC 6274 wies 2011 darauf hin, dass ein IP-Modul mehr Link-Bytes erhalten kann, als Total Length angibt. Legitim ist das häufig wegen Padding; ein Angreifer kann ebenfalls zusätzliche Bytes erzeugen.

Der Empfangspuffer soll deshalb nach der vom Link gemeldeten Nutzlastgröße angelegt werden. Das schützt die Aufnahme des äußeren Containers. Die IP-Auswertung endet trotzdem an Total Length; Speicherberechtigung ist keine Protokollmitgliedschaft.

Ist die Link-Nutzlast kleiner als Total Length, muss das Paket verworfen und das Ereignis protokolliert werden. Fehlende Bytes dürfen nicht aus angrenzendem Speicher ergänzt werden. Außerdem muss IHL mal vier in Total Length passen.

Eine einzige „wahre Paketlänge“ würde eine der beiden Aufgaben verfehlen. Die Link-Länge regiert die Aufnahme, die IP-Länge die Interpretation.

Außerhalb von IP konnte dennoch vertraulicher Inhalt liegen

Die CERT/CC Vulnerability Note VU#412115 berichtete im Januar 2003 von Netzwerktreibern, die kurze Frames nicht mit Null-Oktetten füllten. Stattdessen verwendeten sie alte Daten aus Frame-Puffern. Je nach Implementierung konnten Kernel-Speicher, statische Treiberdaten oder Hardware-Puffer nach außen gelangen.

Ein korrekter IP-Parser hätte diese Bytes weiterhin nicht als Nutzlast gelesen. Ein Ethernet-Nachbar konnte sie trotzdem beobachten. Semantische Ausgrenzung machte die physische Übertragung nicht unsichtbar.

Die CERT-Unterlagen unterscheiden betroffene, nicht betroffene und unbekannte Produkte. Sie belegen keine universelle Verbreitung. Sie belegen den realisierten Mechanismus: Nicht initialisiertes Link-Padding konnte zu entfernter Informationspreisgabe führen.

Wer die Bytes hinzufügt, bleibt für ihren Inhalt verantwortlich. Total Length ist keine Haftungsfreistellung für Speicher, den der Treiber tatsächlich sendet.

Quellen