イーサネットフレーム
Ethernet IIフレーム(設計の主要な参加者であるDEC、Intel、XeroxからDIXイーサネットともいう)は、宛先・送信元MACアドレスの前に、2オクテットのEtherTypeフィールドを定義する。EtherTypeは、フレームデータによってカプセル化された上位層プロトコルを識別するのに使用する。例えば、EtherType値0x0800は、フレームにIPv4データグラムが含まれていることを示す。同様に、0x0806のEtherTypeはARPフレーム、0x86DDはIPv6フレームを示し、0x8100は前述の通りIEEE 802.1Qタグの存在を示す。
この業界標準規格が正式なIEEE標準化プロセスを経るにつれて、EtherTypeフィールドは新しい802.3標準規格のデータ長フィールドに変更された。受信者はまだフレームを解釈する方法を知る必要があるので、規格では長さに続いて、タイプを指定するためにIEEE 802.2ヘッダが要求された。何年も後に、802.3x-1997規格、および802.3規格のそれ以降のバージョンでは、両方の種類のフレーミングが正式に承認された。
フレームチェックシーケンス (FCS) は、受信側でフレーム全体内の破損データの検出を可能にする4オクテットの巡回冗長検査 (CRC) である。FCSの値は、保護されたMACフレームフィールド(送信元アドレスと宛先アドレス、長さ/タイプフィールド、MACクライアントデータ、パディング。つまり、FCS以外の全てのフィールド)の関数として計算される。
CRCコードを含む受信フレームデータに対してCRCアルゴリズムを実行すると、CRCは多項式で除算されたデータの剰余であるため、エラーのない受信データに対しては常にゼロになる。ただし、この手法ではエラーの検出に失敗する可能性があり、末尾にゼロがあるデータも同じゼロ残差になる。これを回避するために、ペイロードデータの最後に付加される前に送信側によってFCSは補数が取られる(ビットごとに反転される)。この方法では、データが正しく受信されたとき、アルゴリズムの結果は常に0xC704DD7B(マジックナンバーまたはCRC32剰余と呼ばれる)になる。これにより、FCSフィールドが実際に開始される場所を知らなくても、フレームを受信してFCSを検証することができる。