イーサネットフレーム
コンピュータネットワークにおいて、イーサネットフレーム（英語: Ethernet frame）とは、イーサネットにおけるフレームであり、データリンク層のプロトコルデータユニットである。イーサネットフレームは、基礎となるイーサネット物理層の転送機構を使用して転送される。つまり、イーサネットリンク上のパケットは、ペイロードとしてイーサネットフレームを転送する。
イーサネットフレームの前には、プリアンブルと開始フレーム識別子（SFD: start frame delimiter）が続く。これらは物理層のイーサネットパケットの一部である。各イーサネットフレームはイーサネットヘッダで始まる。イーサネットヘッダの最初の2つのフィールドは宛先と送信元のMACアドレスである。フレームの中央部はペイロードデータである。ペイロードデータには、フレームで伝送される他のプロトコル（Internet Protocolなど）の任意のヘッダを含む。フレームは、フレームチェックシーケンス(FCS)で終わる。これは、データの転送中の破損を検出するために使用される32ビットの巡回冗長検査(CRC)である。
プリアンブルと開始フレーム識別子
イーサネットパケットは、7オクテットのプリアンブルと1オクテットの開始フレーム識別子（SFD: start frame delimiter）で始まる。プリアンブルは、1と0のビットが交互に現れる56ビット（7バイト）のパターンで構成されているため、ネットワーク上のデバイスは受信クロックを簡単に同期させて、ビットレベルの同期をとることができる。その後に続くSFDで、バイトレベルの同期を提供し、新しい着信フレームをマークする。大きなシンボルの代わりにシリアルビットを送信するイーサネットの変種では、プリアンブルの（コード化されていない）伝送路上のビットパターンは、フレームのSFD部分と合わせて10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011となり、ビットは左から右へ順番に送信される。
SFDは8ビット（1バイト）の値で、イーサネットパケットの最初のフィールドであるプリアンブルの終わりと、イーサネットフレームの始まりを示す。SFDはプリアンブルのビットパターンを崩し、実際のフレームの開始を知らせるように設計されている。SFDの直後に宛先MACアドレスが続く。宛先MACアドレスは、イーサネットフレームの最初のフィールドである。SFDは二進数シーケンス10101011（イーサネットLSBの最初のビット順序で0xD5、10進213）である。
イーサネットMACを物理媒体に接続するには、物理層トランシーバ回路（PHY）が必要である。PHYとMACとの間の接続は物理媒体とは無関係であり、媒体独立インターフェース（MII、GMII、RGMII、SGMII、XGMII）のバスを使用する。ファストイーサネットトランシーバチップはMIIバスを使用する。これは4ビット（1ニブル）幅のバスであるため、プリアンブルは14個の0x5として表され、SFDは（ニブルとして）0x5 0xDとなる。ギガビットイーサネットトランシーバチップは8ビット幅のインターフェイスであるGMIIバスを使用するので、プリアンブルとSFDは0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5（バイト単位）になる。
ヘッダ
ヘッダには、宛先と送信元のMACアドレス（それぞれ6オクテット）、EtherTypeフィールド、およびオプションでIEEE 802.1QタグまたはIEEE 802.1adタグがある。
EtherTypeフィールドの長さは2オクテットであり、2つの異なる目的のために使われる。この値が1500以下の場合は、オクテット単位のでペイロードのサイズを意味し、1536以上の場合は、フレームのペイロードにカプセル化されているプロトコルを示すEtherTypeとして使用されることを示す。EtherTypeとして使用される場合、フレームの長さはパケット間隔と有効なフレームチェックシーケンス（FCS）の位置によって決まる。
IEEE 802.1Qタグ、IEEE 802.1adタグ（オプション）は4オクテットのフィールドで、仮想LANのメンバーシップとIEEE 802.1pプライオリティを示す。タグの最初の2オクテットはタグプロトコル識別子(TPID: Tag Protocol IDentifier)と呼ばれ、フレームが802.1Qまたは802.1adタグ付きであることを示す。802.1Qの場合のTPIDは0x8100、802.1adの場合は0x88a8である。
ペイロード
最小ペイロードサイズは、802.1Qタグが存在する場合は42オクテット、存在しない場合は46オクテットである。実際のペイロードが最小ペイロードよりも小さい場合は、最小ペイロードサイズになるまでパディングバイトが追加される。最大ペイロードサイズは1500オクテットである。非標準のジャンボフレームでは、最大ペイロードサイズを大きくすることができる。
フレームチェックシーケンス
フレームチェックシーケンス(FCS)は、受信側でフレーム全体内の破損データの検出を可能にする4オクテットの巡回冗長検査(CRC)である。FCSの値は、保護されたMACフレームフィールド（送信元アドレスと宛先アドレス、長さ/タイプフィールド、MACクライアントデータ、パディング。つまり、FCS以外の全てのフィールド）の関数として計算される。
CRCコードを含む受信フレームデータに対してCRCアルゴリズムを実行すると、CRCは多項式で除算されたデータの剰余であるため、エラーのない受信データに対しては常にゼロになる。ただし、この手法ではエラーの検出に失敗する可能性があり、末尾にゼロがあるデータも同じゼロ残差になる。これを回避するために、ペイロードデータの最後に付加される前に送信側によってFCSは補数が取られる（ビットごとに反転される）。この方法では、データが正しく受信されたとき、アルゴリズムの結果は常に0xC704DD7B（マジックナンバーまたはCRC32剰余と呼ばれる）になる。これにより、FCSフィールドが実際に開始される場所を知らなくても、フレームを受信して​​FCSを検証することができる。
フレームの終わり（物理層）
フレームの終わり(EOF: end of a frame)は通常、物理層でのデータストリームの終わりのシンボル、またはキャリア信号の消失によって示される。例えば10BASE-Tでは、受信側はキャリアの消失によって送信されたフレームの終わりを検出する。後の仕様の物理層では、特にキャリアがフレーム間で継続的に送信される場合に、曖昧さを避けるために明示的なend of dataまたはend of streamのシンボルやシーケンスを使用する。例えば8b/10bによるギガビットイーサネットでは、フレームが送信される前後に特別なシンボルを送信する。
パケット間隔（物理層）
パケット間隔(IPG: interpacket gap)は、パケット間のアイドル時間である。パケットが送信された後、送信側は次のパケットを送信する前に最低96ビット（12オクテット）のアイドル状態を維持する必要がある。
Ethernet II
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規格のそれ以降のバージョンでは、両方の種類のフレーミングが正式に承認された。Ethernet IIフレームは、その単純さと低いオーバーヘッドにより、イーサネットLANでは最も一般的である。
Ethernet IIのフレーミングを使用するフレームとオリジナルの802.3フレーミングを使用するフレームを同じイーサネットセグメントで使用できるようにするには、EtherType値を1536（0x0600）以上にする必要がある。802.3フレームのペイロードフィールドの最大長が1500オクテット（0x05DC）であるため、その値が選択された。従って、フィールドの値が1536以上の場合、フレームはEthernet IIフレームでなければならず、そのフィールドはEtherTypeを表す。それが1500以下の場合、それはIEEE 802.3フレームでなければならず、そのフィールドは長さを表す。1500と1536の間の値は未定義である。この規約により、ソフトウェアはフレームがEthernet IIフレームかIEEE 802.3フレームかを判断することができ、同じ物理媒体上で両方の規格を共存させることができる。
ノベル raw IEEE 802.3
ノベルのraw 802.3フレームフォーマットは、初期のIEEE 802.3の開発作業に基づくものである。ノベルはこれを出発点として、イーサネットを介した独自のIPXネットワークプロトコルの初の実装を作成した。raw 802.3フレームフォーマットでは、LLCヘッダを使用せず、長さフィールドのすぐ後にIPXパケットが開始する。これはIEEE 802.3規格には準拠していないが、IPXでは常に最初の2オクテットを0xFFとするので（IEEE 802.2 LLCでそのパターンになることは理論的にはあり得るが、極めて可能性が低い）、他のイーサネット実装と同じ物理媒体上で共存できる。ただし、DECnetの初期のいくつかの形式は、この仕様によって混乱している。
ノベルのNetWareは、1990年代半ばまでデフォルトでこのフレームタイプを使用しており、NetWareが広く普及しIPがまだ普及していなかった頃には、世界のイーサネットトラフィックのほとんどはIPXを伝送するraw 802.3フレームフォーマットを介していた。NetWare 4.10以降、IPXを使用するときのNetWareのデフォルトはLLCによるIEEE 802.2（NetWareフレームタイプEthernet_802.2）である。
IEEE 802.2 LLC
OSI参照モデル用に設計されたプロトコルの中には、コネクション型とコネクションレス型の両方のネットワークサービスを提供するIEEE 802.2 LLCカプセル化の上で直接動作するものもある。
IEEE 802.2 LLCのカプセル化は、IPを介したNetWareへの移行がまだ完了していない大企業のNetWare環境を除いて、現在、一般的なネットワークでは広く使用されていない。過去には、多くの企業ネットワークで、IEEE 802.2を使用して、イーサネットとトークンリングやFDDIネットワーク間のトランスペアレント変換ブリッジをサポートしていた。
IEEE 802.2 LLCのSAP/SNAPフレームに、IPv4トラフィックをカプセル化するためのインターネット標準がある。FDDI、トークンリング、IEEE 802.11（EtherTypeを使用する5.9 GHz帯域を除く）やその他のIEEE 802 LANで使用されているが、イーサネットではほとんど実装されていない。IPv6は、IEEE 802.2 LLC SAP/SNAPを使用してイーサネット経由で送信することもできるが、これもまたほとんど使用されていない。
IEEE 802.2 SNAP
802.2 LLCヘッダを調べることによって、その後にSNAPヘッダが続くかどうかを判断することが可能である。LLCヘッダには、OSIの用語で「サービスアクセスポイント」(SAPs: service access points)と呼ばれる2つの8ビットアドレスフィールドが含まれている。送信元と宛先の両方のSAPが値0xAAに設定されている場合、LLCヘッダの後にSNAPヘッダが続く。SNAPヘッダを使用すると、EtherType値を全てのIEEE 802プロトコルで使用でき、プライベートプロトコルIDスペースにも対応できる。
IEEE 802.3x-1997では、MACアドレスの後の16ビットフィールドを長さフィールドまたはタイプフィールドとして使用することを明示的に許可するようにIEEEイーサネット規格が変更された。
Mac OSは、イーサネット上のAppleTalk v2プロトコルスイート(EtherTalk)にIEEE 802.2 LLC+SNAPカプセル化を使用する。
ラントフレーム
ラントフレーム(runt frame)は、IEEE 802.3の最小長64オクテットより短いイーサネットフレームである。ラントフレームは一般に衝突によって引き起こされる。その他の考えられる原因として、ネットワークカードの誤動作、バッファアンダーラン、デュプレックスの不一致、ソフトウェアの不具合がある。