Aller au contenu

Trames Ethernet : structure, formats et lecture dans Wireshark

Une trame Ethernet est l’unité de transmission sur un réseau local. Avant d’interpréter ce que transporte une capture Wireshark, il faut savoir lire l’enveloppe qui encapsule les données, et distinguer les différents formats de trames qui coexistent sur les réseaux modernes.

Le format le plus répandu. Il est défini par la spécification DIX (Digital, Intel, Xerox) et utilisé par la quasi-totalité du trafic IP aujourd’hui.

0 6 12 14 60-1514
┌────────┬────────┬────────┬─────────────────────────────────┬──────┐
│ DST │ SRC │ Type │ Données │ FCS │
│ 6 oct. │ 6 oct. │ 2 oct. │ 46 à 1500 oct. │4 oct.│
└────────┴────────┴────────┴─────────────────────────────────┴──────┘
Champ Taille Rôle
Destination 6 octets Adresse MAC du destinataire
Source 6 octets Adresse MAC de l’émetteur
EtherType 2 octets Identifie le protocole encapsulé
Données 46–1500 oct. Charge utile (payload)
FCS 4 octets Contrôle d’intégrité (CRC-32)

Le champ EtherType identifie le protocole de couche 3 transporté :

Valeur Protocole
0x0800 IPv4
0x0806 ARP
0x86DD IPv6
0x8100 VLAN (802.1Q)
0x8847 MPLS unicast
0x88CC LLDP

La règle de distinction entre Ethernet II et 802.3 : si la valeur du champ en position 12-13 est supérieure à 1500 (0x05DC), c’est un EtherType → Ethernet II. Si elle est inférieure ou égale à 1500, c’est une longueur → 802.3.


Défini par l’IEEE. Le champ en position 12-13 indique ici la longueur des données, pas le protocole. L’identification du protocole est déléguée aux couches supérieures (LLC).

0 6 12 14 60-1514
┌────────┬────────┬────────┬─────────────────────────────────┬──────┐
│ DST │ SRC │ Lng. │ Données │ FCS │
│ 6 oct. │ 6 oct. │ 2 oct. │ 46 à 1500 oct. │4 oct.│
└────────┴────────┴────────┴─────────────────────────────────┴──────┘

La taille minimale d’une trame Ethernet (hors préambule) est de 64 octets. Si les données ne remplissent pas les 46 octets minimaux, un bourrage (padding) est ajouté.

La taille maximale est de 1518 octets (1514 + FCS), soit une MTU de 1500 octets pour le payload IP.


Quand une trame 802.3 transporte un protocole identifié par LLC, les 3 premiers octets de données contiennent l’en-tête LLC :

┌──────┬──────┬─────────┬──────────────────────┐
│ DSAP │ SSAP │ Control │ Données │
│1 oct.│1 oct.│ 1 oct. │ │
└──────┴──────┴─────────┴──────────────────────┘
Champ Rôle
DSAP Destination Service Access Point, identifie le protocole destinataire
SSAP Source Service Access Point, identifie le protocole source
Control Type de trame LLC (UI = 0x03 pour données non confirmées)
Valeur Protocole
0x00 Null LSAP
0x06 IP (dans les vieux réseaux)
0xAA SNAP
0xFE IS-IS
0xFF Broadcast

Quand DSAP = SSAP = 0xAA, un en-tête SNAP de 5 octets suit immédiatement le LLC. C’est le mécanisme défini par la RFC 1042 pour transporter des protocoles Ethernet II dans des trames 802.3.

┌──────┬──────┬─────────┬─────────────────┬──────────┬──────────────┐
│ DSAP │ SSAP │ Control │ OUI │EtherType │ Données │
│0xAA │0xAA │ 0x03 │ 3 octets │ 2 octets │ │
└──────┴──────┴─────────┴─────────────────┴──────────┴──────────────┘
└──────────── LLC (3 oct.) ──────────────┘└── SNAP (5 oct.) ────────┘
Champ Taille Valeur typique
DSAP 1 octet 0xAA
SSAP 1 octet 0xAA
Control 1 octet 0x03 (UI frame)
OUI 3 octets 0x000000 (IEEE — protocoles standard)
EtherType 2 octets 0x0800 (IP), 0x0806 (ARP)…

L’overhead total LLC + SNAP est de 8 octets, réduit d’autant la place disponible pour le payload.


Ethernet II
┌─────┬─────┬──────────┬──────────────────┬─────┐
│ DST │ SRC │EtherType │ Payload │ FCS │
└─────┴─────┴──────────┴──────────────────┴─────┘
802.3 brut
┌─────┬─────┬──────────┬──────────────────┬─────┐
│ DST │ SRC │ Longu. │ Payload │ FCS │
└─────┴─────┴──────────┴──────────────────┴─────┘
802.3 + LLC
┌─────┬─────┬──────────┬─────────────┬────────────────┬─────┐
│ DST │ SRC │ Longu. │ LLC 3 oct. │ Payload │ FCS │
└─────┴─────┴──────────┴─────────────┴────────────────┴─────┘
802.3 + LLC + SNAP
┌─────┬─────┬──────────┬─────────────┬──────────────┬────────────┬─────┐
│ DST │ SRC │ Longu. │ LLC 3 oct. │ SNAP 5 oct. │ Payload │ FCS │
└─────┴─────┴──────────┴─────────────┴──────────────┴────────────┴─────┘

Sélectionner un paquet → dérouler Ethernet II dans le panneau de détail. Wireshark indique explicitement le format :

Ethernet II, Src: aa:bb:cc:dd:ee:ff, Dst: 11:22:33:44:55:66
Destination: 11:22:33:44:55:66
Source: aa:bb:cc:dd:ee:ff
Type: IPv4 (0x0800) ← EtherType → Ethernet II

Pour une trame 802.3 avec LLC :

IEEE 802.3 Ethernet
Destination: ff:ff:ff:ff:ff:ff
Source: aa:bb:cc:dd:ee:ff
Length: 60 ← longueur → 802.3
Logical-Link Control
DSAP: SNAP (0xaa)
SSAP: SNAP (0xaa)
Control field: U, func=UI (0x03)
SubNetwork Access Protocol
Organization Code: Encapsulated Ethernet (0x000000)
Type: ARP (0x0806)
# Trames Ethernet II transportant IPv4
eth.type == 0x0800
# Trames ARP
eth.type == 0x0806
# Trames VLAN taggées
eth.type == 0x8100
# Filtrer par adresse MAC source
eth.src == aa:bb:cc:dd:ee:ff
# Filtrer par adresse MAC destination (broadcast)
eth.dst == ff:ff:ff:ff:ff:ff
# Trames LLC avec SNAP
llc.dsap == 0xaa
# Afficher uniquement les trames d'un constructeur (3 premiers octets du MAC)
eth.src[0:3] == 00:50:56 # VMware
eth.src[0:3] == b8:27:eb # Raspberry Pi Foundation

Les 3 premiers octets d’une adresse MAC (OUI — Organizationally Unique Identifier) identifient le fabricant. Wireshark les résout automatiquement dans l’affichage. En audit, cela permet de qualifier rapidement les équipements présents sur un segment réseau sans configuration réseau supplémentaire.

aa:bb:cc:dd:ee:ff
└─────┘
OUI → fabricant de la carte réseau

Menu Statistics → Protocol Hierarchy : Wireshark affiche la répartition du trafic par protocole sur toute la capture, pratique pour identifier rapidement quels protocoles circulent et en quelle proportion.

Sur un réseau moderne, le trafic est quasi exclusivement en Ethernet II avec EtherType 0x0800 (IPv4) ou 0x86DD (IPv6). Les formats 802.3 + LLC + SNAP se rencontrent principalement dans des contextes Wi-Fi (802.11) ou sur des équipements réseau anciens. Savoir distinguer ces formats dans Wireshark évite de mauvaises interprétations lors de l’analyse d’une capture.