IPv6の「素顔」を暴く：EUI-64の光と影、そして現代の境界防御
ネットワークエンジニア諸君、今日もパケットの海を泳いでいるだろうか。
OSI参照モデルの第2層（データリンク層）から第3層（ネットワーク層）へ、パケットが昇華する瞬間。我々は往々にしてIPv4の枯渇という亡霊に追われ、IPv6という広大なフロンティアへ足を踏み入れる。だが、そこにはIPv4時代には存在しなかった、あるいは意識すらしなかった「リンクローカルアドレス」という名の、あまりにも雄弁な識別子が待ち受けている。
今回は、IPv6の自動生成メカニズムである EUI-64 に焦点を当て、それがインフラアーキテクトやセキュリティ専門家にとって何を意味するのか、徹底的に解剖していく。
—
EUI-64：MACアドレスから導き出される「宿命」
IPv6の link-local address（fe80::/10）を生成する際、ステートレスアドレス自動設定（SLAAC）は多くの場合 EUI-64 フォーマットを採用する。これは、48ビットのMACアドレスの中央に 0xfffe を挿入し、先頭から7ビット目を反転させるという、極めて機械的な変換ロジックだ。
# MACアドレス: 00:11:22:33:44:55 からの EUI-64 変換例
# 1. 中央に 0xfffe を挿入
# 00:11:22:ff:fe:33:44:55
# 2. 先頭バイト(00)をバイナリにし、7ビット目を反転 (0x02)
# 結果: 0211:22ff:fe33:4455この仕様の恐ろしい点は、「世界中どこにいても、そのインターフェースIDが物理的に不変である」という点にある。つまり、MACアドレスというハードウェア固有の識別子が、ネットワーク層のグローバルなコンテキストに直結してしまうのだ。
現場で直面する「追跡可能性」の脆弱性
かつて、この仕組みは管理の自動化という点では福音だった。しかし、セキュリティの観点から見れば最悪の設計だ。デバイスが異なるネットワーク間を移動しても、そのインターフェースIDが一致していれば、同一デバイスであることは明白である。これが「プライバシー拡張（RFC 4941）」が切望された理由だ。
現代のLinuxカーネル（sysctl）では、デフォルトでこれらを制御可能だが、まずは現状を確認しよう。
# カーネルパラメータでプライバシー拡張の挙動を確認
# 0: 無効, 1: 有効(デフォルト), 2: テンポラリアドレスを優先
sysctl net.ipv6.conf.all.use_tempraddr—
パフォーマンスとセキュリティの最適化：カーネルチューニングの勘所
ハイパフォーマンスなインフラ環境では、IPv6のバッファリングと TCP のハンドシェイク最適化が直結する。特に、RTT（Round Trip Time）の削減は、TLSハンドシェイクの遅延を抑えるための生命線だ。
TCPバッファとウィンドウサイズの最適化
IPv6環境では、ヘッダーの肥大化（40バイト固定）に伴い、MTUサイズの影響がIPv4以上にシビアになる。パケットロス発生時の再送制御を最適化するため、以下のようなチューニングを sysctl.conf に適用するのが定石だ。
# /etc/sysctl.conf への追記サンプル
# TCPウィンドウのスケーリングを最適化し、スループットを向上させる
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 輻輳制御アルゴリズムを BBR に変更（Google開発の最新アルゴリズム）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrTLSハンドシェイクの最適化
TLS 1.3が普及した現在、0-RTT（Early Data）の使用は強力な武器だが、リプレイアタックのリスクを孕む。セキュリティ専門家として、このトレードオフをどう管理するか。
もしあなたがロードバランサーやリバースプロキシ（Nginx等）を構築しているなら、IPv6のアドレス生成方式に関わらず、フロントエンドで徹底したTLSネゴシエーションの強制を行うべきだ。
# Nginxの設定例: IPv6対応とTLS 1.3の最適化
server {
listen [::]:443 ssl http2;
ssl_protocols TLSv1.3;
ssl_early_data on; # 0-RTTを有効化（防御策とセットで導入すること）
# 接続元IPベースのレートリミット（EUI-64の懸念を緩和するために重要）
limit_req zone=addr burst=10 nodelay;
}—
結びに：境界防御の再定義
我々が守るべきは、単なる「IPアドレス」ではない。パケットが運ぶ「コンテキスト」だ。
EUI-64 が生成する静的な識別子は、攻撃者にとっての「格好の追跡用タグ」になり得る。だが、プライバシー拡張アドレスを導入し、カーネルレベルでスタックを調整し、TLS 1.3でセッションを保護する。これら一つ一つの泥臭い積み重ねこそが、ゼロトラスト時代の境界防御の正体だ。
ネットワークは生き物だ。パケットのヘッダーが刻むビットの羅列に、常に想像力を働かせてほしい。今日の設定変更が、明日、貴方のシステムのボトルネックを解消し、あるいは致命的な脆弱性を防ぐ一撃になることを願っている。
諸君、素晴らしいネットワークライフを。
コメント