3.2 Ethernet-Frame

Der klassische Ethernet-MAC-Frame

Ein ungetaggter Ethernet-MAC-Frame besteht aus 6 Byte Zieladresse, 6 Byte Quelladresse, 2 Byte Length/Type, 46 bis 1500 Byte Datenfeld einschließlich möglichem Padding und 4 Byte FCS. Daraus ergeben sich gewöhnlich 64 bis 1518 Byte von der Zieladresse bis einschließlich FCS. Die Präambel mit 7 Byte und der Start Frame Delimiter mit 1 Byte werden auf dem Medium vorangestellt.

Zwischen zwei Übertragungen liegt bei klassischer Betrachtung ein Interpacket Gap von 96 Bitzeiten, entsprechend 12 Bytezeiten. Diese Pause wird nicht als Datenfeld übertragen und gehört weder zum MAC-Frame noch zur FCS-Berechnung. Moderne PHYs können Details intern anders codieren; für die Ethernet-Grundlagen bleibt die Bytezeitendarstellung das verständliche Bezugsmodell.

Ziel- und Quell-MAC-Adresse

Die Zieladresse steht zuerst, damit eine Netzwerkkarte beziehungsweise ein Switch früh entscheiden kann, ob der Frame relevant ist. Die Quelladresse folgt und muss bei gewöhnlichen Ethernet-Frames eine Individualadresse sein. Switches lernen aus ihr, an welchem Port eine MAC-Adresse innerhalb eines VLANs erreichbar ist.

Das niederwertigste Bit des ersten übertragenen Adressoktets kennzeichnet Individual- oder Gruppenadresse. Das nächsthöhere Bit unterscheidet universell und lokal verwaltete Adressen. Broadcast verwendet FF:FF:FF:FF:FF:FF. Moderne Betriebssysteme können beispielsweise aus Datenschutzgründen lokal verwaltete, wechselnde WLAN-MAC-Adressen einsetzen.

Length oder EtherType?

Das 2-Byte-Feld nach der Quelladresse wird abhängig vom Wert interpretiert. Werte bis einschließlich 1500 geben die Länge der folgenden MAC-Client-Daten an. Werte ab 1536, hexadezimal 0x0600, sind EtherTypes. Der Bereich 1501 bis 1535 ist für diese Unterscheidung nicht als regulärer Längen- oder EtherType-Wert vorgesehen.

Ethernet II verwendet einen EtherType und ist für IP-Verkehr heute die übliche Kapselung. IPv4 verwendet 0x0800, ARP 0x0806 und IPv6 0x86DD. Bei einer Längenangabe folgt typischerweise IEEE 802.2 LLC und gegebenenfalls SNAP, um das höhere Protokoll zu identifizieren.

802.1Q-VLAN-Tag

Ein einfach getaggter IEEE-802.1Q-Frame erhält vier zusätzliche Byte. Der Tag Protocol Identifier, TPID, ist bei einem gewöhnlichen C-Tag 0x8100. Danach folgt die Tag Control Information mit drei Bit Priority Code Point, einem Bit Drop Eligible Indicator und zwölf Bit VLAN Identifier.

Die zwölf Bit erlauben 4096 Zahlenwerte. VLAN-ID 0 kennzeichnet nur Prioritätsinformation und VLAN-ID 4095 ist reserviert; für gewöhnliche VLAN-Zuordnungen bleiben 1 bis 4094. PCP stellt eine Layer-2-Prioritätsmarkierung bereit, garantiert aber ohne passende Warteschlangen- und Pfadkonfiguration keine Dienstgüte.

Nutzdaten, Padding und MTU

Die gewöhnliche Ethernet-MTU beträgt 1500 Byte. Sie bezeichnet die maximal ohne zusätzliche Ethernet-Sonderform in das Datenfeld passende Layer-3-PDU, beispielsweise ein IP-Paket. Ethernet-Header und FCS gehören nicht zur IP-MTU. Ist die Nutzlast zu kurz, ergänzt der Sender Padding, damit die Mindestframegröße erreicht wird.

Bei IPv4 enthält das Total-Length-Feld nur das IP-Paket und nicht das Ethernet-Padding. Der Empfänger erkennt deshalb, wo das IP-Paket endet. Jumbo Frames erlauben größere Datenfelder, sind aber nicht durch eine einzige universelle Ethernet-Größe vereinheitlicht. Alle Geräte und Links des Pfads müssen die gewählte Größe unterstützen; andernfalls entstehen Drops oder Fragmentierungsprobleme.

FCS und CRC

Die vier Byte lange Frame Check Sequence enthält das Ergebnis einer CRC-32-Berechnung. Sie schützt den Bereich von der Zieladresse über Header, Nutzdaten und Padding. Präambel und SFD gehören nicht zur Berechnung. Erkennt der Empfänger eine Abweichung, wird der Frame normalerweise verworfen und ein Fehlerzähler kann steigen.

Die FCS ist keine kryptografische Signatur: Ein Angreifer kann Daten und Prüfsumme gezielt neu berechnen. Außerdem wird die FCS von Netzwerkkarten häufig bereits geprüft und entfernt, bevor ein Paketmitschnitt das Betriebssystem erreicht. Dass Wireshark keine FCS anzeigt, beweist deshalb nicht, dass auf dem Medium keine übertragen wurde.

• CRC erkennt viele typische Übertragungsfehler, korrigiert die Nutzdaten aber nicht.
• Switches berechnen beim Weiterleiten einen neuen gültigen Frame für den Ausgangsport.
• Steigende FCS-Fehler können auf Medium, Stecker, Transceiver, Duplex-/PHY-Probleme oder Störungen hinweisen.
• Capture-Hardware und Treiber bestimmen, ob FCS und beschädigte Frames sichtbar sind.

Kapselung von TCP über IPv4

Ein typisches Beispiel ohne Optionen verwendet 1500 Byte IP-Paketgröße. Davon belegt der minimale IPv4-Header 20 Byte. Im verbleibenden TCP-Segment belegt der minimale TCP-Header weitere 20 Byte. Damit ergibt sich eine TCP Maximum Segment Size von 1460 Byte. TCP- oder IP-Optionen verringern den Platz für Anwendungsdaten.

Bei IPv6 beträgt der Basisheader 40 Byte. Ohne Erweiterungsheader und mit minimalem TCP-Header ergibt sich bei derselben 1500-Byte-MTU eine TCP-MSS von 1440 Byte. Die MSS bezeichnet TCP-Nutzdaten, nicht die Größe des TCP-Segments oder Ethernet-Frames.

Was belegt tatsächlich das Medium?

Bei einem ungetaggten Frame mit 1500 Byte Datenfeld umfasst der MAC-Frame 1518 Byte. Mit Präambel und SFD werden 1526 Byte übertragen; zusammen mit dem Interpacket Gap belegt die Übertragung 1538 Bytezeiten. Das Verhältnis von 1500 Byte Nutzdaten zu 1538 Bytezeiten beträgt ungefähr 97,5 Prozent. Weitere Protokollheader reduzieren den Anteil echter Anwendungsdaten zusätzlich.

Kleine Frames verursachen relativ mehr Overhead. Ein minimaler 64-Byte-MAC-Frame belegt zusammen mit Präambel, SFD und Gap 84 Bytezeiten. Durchsatzangaben müssen daher klären, ob sie Leitungsgeschwindigkeit, MAC-Frame-Rate, IP-Durchsatz oder Anwendungsdaten meinen.

Frames im Paketmitschnitt lesen

• VLAN- und Prüfsummen-Offloading kann einen lokalen Mitschnitt anders aussehen lassen als den Frame auf dem Kabel.
• Preamble, SFD und Interpacket Gap erscheinen in gewöhnlichen Software-Captures nicht.
• Ein Router ersetzt den Ethernet-Header; die MAC-Adressen bleiben daher nicht Ende zu Ende gleich.