6バイトの呪縛：MACアドレスの「I/Gビット」が決定づけるパケットの運命
ネットワークエンジニアの諸君、今日も今日とて tcpdump の出力結果を眺めているだろうか。我々が日常的に扱うイーサネットフレーム、その冒頭に鎮座する12バイトの送信元・宛先MACアドレス。これらを単なる「ハードウェア識別子」と捉えているなら、それはあまりに勿体ない。
この6バイトの並びには、スイッチング・ファブリックの挙動を根本から支配する「神のビット」が隠されている。今回は、特に第1バイトの最下位ビット（LSB）、いわゆる I/Gビット（Individual/Group bit） が、高負荷なL2環境やセキュリティ要件が厳しいトランスポート層にどのような波及効果をもたらすのか、その深淵を覗いてみよう。
—
1. I/Gビット：スイッチングの運命を分かつ境界線
MACアドレスの第1オクテットのLSB、これを「I/Gビット」と呼ぶ。このビットが 0 であればユニキャスト、1 であればマルチキャストであることは教科書にも書かれている。しかし、現場のアーキテクトが意識すべきは、スイッチのASICがこのビットをどう処理するかという「物理的コスト」だ。
- I/G = 0 (Individual): ユニキャスト。CAMテーブル（MACアドレス学習テーブル）を参照し、ポートを特定してダイレクトにパケットを射出する。これはスイッチングにおいて最も効率的かつ低レイテンシなパスだ。
- I/G = 1 (Group): マルチキャスト。ここで重要になるのは、スイッチが「フラッディング」を行うか、「IGMP/MLDスヌーピング」によって制御されたマルチキャストを行うかだ。
- FF:FF:FF:FF:FF:FF (Broadcast): I/Gビットが
1であることは自明だが、全ビットが1である特別枠。これはスイッチの全ポートへの複製を意味する。
なぜこれがパフォーマンスを左右するのか
高負荷なデータセンター環境において、むやみなマルチキャストやブロードキャストは「CPU割り込みの嵐」を招く。特に、トラフィックの多い環境で無秩序なブロードキャストが発生すると、NICのバッファ溢れ（Ring Buffer Overrun）を引き起こし、結果として上位レイヤーの TCP 再送を誘発する。これは RTT 増大の直接的な原因となる。
—
2. パケットレベルの最適化とTCPバッファチューニング
L2の挙動を最適化した後は、トランスポート層での「血の通ったチューニング」が必要だ。特に TLS ハンドシェイクが絡む場合、RTT削減は至上命題となる。
ブロードキャストや不要なマルチキャストによるジッターを最小化しつつ、TCPスタックを最適化するための sysctl 設定例を挙げる。これらは、パケットロスに対する耐性を高め、ハンドシェイクの高速化に直結する。
# TCPウィンドウのスケーリングを有効化し、帯域幅遅延積（BDP）を最大化
sysctl -w net.ipv4.tcp_window_scaling=1
# TCPの初期輻輳ウィンドウ（initcwnd）を大きくして、最初のハンドシェイクで送信できるデータ量を増やす
# 10セグメントに設定することで、小さなHTTPSリクエストなら1 RTTで完了させる
ip route change default via 192.168.1.1 dev eth0 initcwnd 10
# バッファの自動チューニング範囲を拡大
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"—
3. セキュリティ：MACスプーフィングとARPの闇
MACアドレスのI/Gビットを悪用する攻撃は、古典的だが依然として強力だ。特に、Gratuitous ARP を用いてデフォルトゲートウェイになりすます攻撃は、L2スイッチのCAMテーブルを汚染する。
これを防ぐためには、単なるポートセキュリティではなく、DHCP Snooping と Dynamic ARP Inspection (DAI) を組み合わせた「防衛的スイッチング」が不可欠だ。
# Cisco IOSでのDAI設定例：ARPパケットの正当性を確認し、不正なMAC/IPバインディングを遮断する
ip arp inspection vlan 10-20
interface GigabitEthernet0/1
description Trusted_Uplink
ip arp inspection trust—
4. ヘッダー圧縮の視点：RoCEやRDMAへの応用
現代の超低遅延ネットワークでは、イーサネットフレームのオーバーヘッドすら削る必要がある。RoCE (RDMA over Converged Ethernet) では、L2ヘッダーを保持しつつ、L3/L4のオーバヘッドを極限まで排除する。
ここでは、MACアドレスのI/Gビット管理がさらに厳格になる。PFC（Priority-based Flow Control）を有効化し、特定のクラスのトラフィックにおいて「ロスレス・イーサネット」を実現する場合、マルチキャストトラフィックがPFCのバッファを枯渇させないよう、VLAN 分離による論理的なブロードキャストドメインの縮小が必須となる。
アーキテクトへの提言
諸君が設計するネットワークにおいて、以下のチェックリストを常に念頭に置いてほしい。
1. ブロードキャストドメインの最小化: VLANを適切に切り、ARPが飛び交う範囲を物理的・論理的に制限せよ。
2. I/Gビットの可視化: tcpdump -e でフレームを確認する際、MACアドレスだけでなく、そのビットが意味するトポロジーの広がりを想像せよ。
3. カーネルチューニングの定点観測: netstat -s で retransmits や packet loss を監視し、それがL2の輻輳に起因するものか、上位レイヤーのパラメータに起因するものかを切り分けよ。
パケットは嘘をつかない。たとえそれが6バイトのMACアドレスであっても、そこに刻まれた「I/Gビット」というわずか1ビットの差異が、ネットワーク全体のパフォーマンスとセキュリティを決定づけるのだ。
さあ、次は君のターミナルで tshark を走らせ、そのパケットがどのポートへ、どのような意図で運ばれているのかを追跡してみよう。ネットワークの深淵は、意外とすぐそこにある。
コメント