【実務・中級編】 MACアドレスフォーマット（EUI-48 / MAC-48）の構造とOUI（Organizationally Unique Identifier） – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

ネットワークの「名前」を読み解く：MACアドレス、その48ビットに隠された静かなる秩序

ネットワークエンジニアとして現場に立つと、トラブルの最前線で必ずと言っていいほどお世話になるのが MACアドレス です。IPアドレスが「どこへ行くか」という論理的な住所なら、MACアドレスは「どのハードウェアか」という、逃げ場のない物理的なアイデンティティです。

今日は、教科書的な定義をなぞるのではなく、パケットを捉えるアナライザーの向こう側に見える「MACアドレスの真実」を、現場の視点から紐解いていきましょう。

1. 48ビットの構造：OUIが語る「出自」

MACアドレスは48ビット（6バイト）で構成されています。これを「適当な識別子」と捉えているなら、それは非常にもったいない。この文字列には、製造元のプライドと、通信のルールが刻まれています。

前半24ビット：OUI（Organizationally Unique Identifier）

最初の24ビットはIEEEが各ベンダーに割り当てる「ベンダー識別子」です。例えば、00:0C:29 が見えれば「あ、これはVMwareの仮想NICだな」と瞬時に判断できます。トラブルシューティングにおいて、パケットキャプチャの送信元に未知のベンダーが紛れ込んでいた場合、このOUIを確認するだけで、不正なデバイスや設定ミスを切り分ける強力なヒントになります。

後半24ビット：NIC固有ID

残りの24ビットは、そのベンダーが製造したNICごとに割り当てるシリアル番号のようなものです。

2. 実務で知っておくべき「魔法の2ビット」

MACアドレスの最初のバイトには、実はエンジニアが絶対に知っておくべき「通信の制御ビット」が含まれています。

I/Gビット（Individual/Group）:
0 ならユニキャスト（特定のデバイス宛）
1 ならマルチキャスト（グループ宛）
U/Lビット（Universal/Local）:
0 ならユニバーサル（IEEEが管理するグローバルに一意なID）
1 ならローカル（ネットワーク管理者が任意に設定したアドレス）

特に仮想化環境やコンテナネットワークを構築する際、管理者が意図的にMACアドレスを固定する（U/L ビットを立てる）ケースは珍しくありません。クラウドのAPI経由でNICをプロビジョニングする際、なぜ特定のMACアドレスが弾かれるのか――その理由は、このビット構造に反しているからかもしれません。

3. 実践：PythonでMACアドレスを分解・検証する

インフラ運用において、ログや設定ファイルからMACアドレスを抽出・検証する機会は多いはずです。Pythonを使って、MACアドレスのOUIを確認する簡単なスクリプトを作成してみましょう。

def analyze_mac(mac_address):
    # コロンで分割してリスト化
    parts = mac_address.split(':')
    
    # 最初の3バイトがOUI
    oui = ":".join(parts[:3]).upper()
    
    # I/Gビットの確認 (最初のバイトの最下位ビット)
    first_byte = int(parts[0], 16)
    is_multicast = (first_byte & 0x01) != 0
    
    print(f"MAC Address: {mac_address}")
    print(f"OUI: {oui}")
    print(f"Type: {'Multicast' if is_multicast else 'Unicast'}")

# 使用例
analyze_mac("00:0c:29:ab:cd:ef")

このように、コードレベルでパケットのヘッダーをパースできるようになると、異常なトラフィックを検知する軽量な監視スクリプトを自前で実装できるようになります。

4. Web APIとMACアドレスの「距離感」

Webエンジニアからよく相談されるのが、「Web APIでクライアントのMACアドレスは取れないのか？」という問いです。

答えは「Layer 3を越えた先には届かない」です。

MACアドレスはL2（データリンク層）の概念であり、ルーターを越えるとパケットは再構築され、送信元MACアドレスは「次のホップのルーター」に書き換わります。もしAPI経由でクライアントのMACを取得したい場合、それは同一セグメント内（L2ドメイン）である必要があります。

デバッグの心得：ARPテーブルを確認する

現場で「通信が疎通しない」という連絡を受けたとき、まずはゲートウェイのARPテーブルを確認しましょう。Linuxであれば以下のコマンドが定石です。

# ARPテーブルの確認（特定のIPのMACを確認）
ip neigh show 192.168.1.1

# リアルタイムでARPの解決状況を監視
watch -n 1 'arp -a'

このコマンドで INCOMPLETE と表示されているなら、それはパケットが物理的・論理的に届いていない（L2の断絶）ことを示唆しています。

最後に：ネットワークは「行間」を読む

MACアドレス一つとっても、そこにはIEEEの定めた厳格な標準と、現場のエンジニアが工夫を凝らした実装の歴史が詰まっています。

「動いているからいいや」ではなく、「このMACアドレスはどこのベンダーか？」「なぜこのビットが立っているのか？」と問いかける姿勢こそが、大規模障害を防ぐ最後の砦となります。皆さんもぜひ、次に tcpdump や Wireshark を開くときは、この48ビットの背後にある物語に耳を澄ませてみてください。

ネットワークの世界は、まだまだ深淵で、面白いですよ。