Windows Server 2012 R2 の DHCP を使って iPXE を IPv6（DHCPv6）で起動しようとすると、「DHCPv4 の Option 67（ブートファイル名）が見当たらない」壁に当たります。本記事では DHCPv6 の“渡し方”の違い（Bootfile URL / Option 59）と、Windows DHCP での定義・設定手順、つまずきやすいポイントと回避策までまとめます。
結論：DHCPv6 では「ブートファイル名」を単体で渡すのではなく、Bootfile URL（Option 59）で“場所ごと”渡す
まず押さえておきたいのは、DHCPv6 は DHCPv4 の延長線で「Option 66（TFTPサーバー）＋Option 67（ブートファイル名）」をそのまま置き換える設計ではない、という点です。DHCPv6 のネットワークブートは、URL（URI）として “取得先” をまとめて渡すのが基本になります。
そのため、DHCPv4 でお馴染みの Option 67 相当を DHCPv6 の GUI 上で探しても、見つからない（または用意されていない）ことが多いです。代わりに使うのが、RFC 5970 で定義されている DHCPv6 Option 59（Bootfile URL / OPT_BOOTFILE_URL）です。
| 項目 | DHCPv4 でよく使う設定 | DHCPv6 での考え方 |
|---|---|---|
| ブートファイルの指定 | Option 67（例：ipxe.efi / undionly.kpxe） | Option 59（例：tftp://[IPv6]/ipxe.efi、http://[IPv6]/ipxe.efi） |
| 配布元サーバーの指定 | Option 66（TFTP Server Name） | URL のホスト部に含める（IPv6 は角括弧で囲む） |
| プロトコル | TFTP が中心 | HTTP/TFTP など（URL の scheme で指定） |
Option 59（Bootfile URL）で渡す値の具体例
Option 59 の中身は「どこから何を取るか」を表す URL（URI）です。IPv6 アドレスを URL に書く場合は、角括弧 [] で囲む必要があります（これは iPXE だけでなく URL の一般ルールです）。
よく使う例は次の通りです。
- HTTP で iPXE バイナリを配布：
http://[2001:db8::1]/ipxe/ipxe.efi - TFTP で iPXE バイナリを配布：
tftp://[2001:db8::1]/ipxe/ipxe.efi - HTTP で iPXE スクリプトを配布（すでに iPXE が起動できる環境向け）：
http://[2001:db8::1]/ipxe/start.ipxe
実務では、最初の 1 ファイルだけを DHCP（Option 59）で渡し、以降の分岐や詳細な処理は iPXE スクリプト側で行う構成が扱いやすいです。特に IPv6 環境は機器差（UEFI ファームウェアの実装差、TFTP サーバーの IPv6 対応差、RA/DHCPv6 の混在など）が出やすいため、まずはシンプルに「確実に 1 つ取得できる形」を作るのが近道です。
前提整理：IPv6 でのネットワークブートは「UEFI」「DHCPv6」「配布サーバーのIPv6待受」の3点がそろって初めて成立する
Option 59 を入れたのに動かない場合、設定以前に前提が崩れているケースが少なくありません。先にチェックしておくと、無駄な試行錯誤を減らせます。
| チェック項目 | よくある落とし穴 | 確認・対処のヒント |
|---|---|---|
| クライアントが IPv6 PXE/HTTP Boot に対応 | 古い機器や BIOS ブートは IPv6 PXE 非対応のことがある | UEFI 設定画面で「IPv6 Network Boot」「UEFI PXE IPv6」などの項目を確認 |
| クライアントが DHCPv6 を実際に投げている | SLAAC（RA）だけでアドレスが付いても DHCPv6 を使わない構成がある | スイッチのSPANやWiresharkで DHCPv6 を捕捉（フィルタ：dhcpv6） |
| 配布サーバーが IPv6 で待ち受けている | TFTP/HTTP サーバーが IPv4 のみ待受で、IPv6 だと到達できない | サーバー側で IPv6 リッスン確認、ファイアウォールの受信許可（HTTP: TCP 80 など） |
Windows Server 2012 R2 DHCP で Option 59 を使う手順（GUI）
Windows Server（Microsoft DHCP）は、DHCPv6 のブート系オプションが「標準で事前定義されていない」ことがあります。その場合は、カスタムの事前定義オプションとして Option 59 を作ってから、スコープやサーバーに値を割り当てます。
手順1：Option 59（Bootfile URL）を事前定義オプションとして追加する
- DHCP 管理コンソール（
dhcpmgmt.msc）を開きます。 - 対象の DHCP サーバーを展開し、IPv6 側の管理ツリーを確認します。
- 「事前定義オプション」（Predefined Options）に相当する項目を探し、新しいオプションの定義を追加します。
- オプション番号に 59、データ型に 文字列（String）、名前に Bootfile URL（分かりやすい名称）を設定します。
ポイントは、Option 59 の値を「サーバー名」と「ファイル名」に分けず、URL を丸ごと 1 本の文字列として定義することです。
手順2：サーバーオプションまたはスコープオプションで Option 59 の値を設定する
次に、作成した Option 59 をどこに適用するかを決めます。
- サーバーオプション：その DHCP サーバー配下の IPv6 スコープ全体に効かせたい場合
- スコープオプション：特定の IPv6 プレフィックス（スコープ）だけに効かせたい場合
- IPv6 の「サーバーオプション」または対象スコープの「スコープオプション」を右クリックし、「オプションの構成」に進みます。
- 一覧から先ほど追加した Bootfile URL（Option 59） を選びます。
- 値にブート用 URL を入力します（例：
http://[2001:db8::1]/ipxe/ipxe.efi）。
入力値は、まずは HTTP を推奨します。理由はシンプルで、HTTP の方が「IPv6 で待ち受けできる実装が多い」「ログが見やすい」「TFTP よりトラブルシュートしやすい」からです。TFTP で始めると、サーバー側が IPv4 しか受けていない／ファイアウォールで落ちている／パスの解釈が実装依存、などで詰まりがちです。
GUI で Option 59 が一覧に出ない・設定がしづらいときの回避策
Windows Server 2012 R2 の DHCP 管理 UI は、DHCPv6 のカスタムオプションを追加できても、環境によっては一覧表示や選択がしづらいという報告があります。GUI で詰まる場合は、PowerShell でオプション定義と値設定を行うと安定します。
PowerShell で Option 59 を定義・設定する例
以下は「Option 59 を定義し、特定の IPv6 スコープに Bootfile URL を設定する」イメージです。サーバー名やスコープ ID（プレフィックス）は環境に合わせて置き換えてください。
# Option 59（Bootfile URL）を定義（未定義の場合）
Add-DhcpServerv6OptionDefinition `
-Name "Bootfile URL" `
-OptionId 59 `
-Type String `
-Description "RFC5970: Bootfile URL (OPT_BOOTFILE_URL)"
# スコープ（例：2001:db8:1234:10::/64）に Option 59 を設定
Set-DhcpServerv6OptionValue `
-ScopeId 2001:db8:1234:10:: `
-OptionId 59 `
-Value "http://[2001:db8::1]/ipxe/ipxe.efi"
PowerShell を使うメリットは、UI に依存せず再現性のある設定を残せることです。検証・本番の差分管理もしやすくなります。
iPXE の設計ポイント：最初は「ipxe.efi を渡す」→「start.ipxe を HTTP で引く」の2段階にすると強い
IPv6 ブートでハマりやすいのが、いきなり複雑な分岐（機種判定、メニュー、OSごとの分岐）を DHCP 側に寄せてしまう構成です。DHCP は「渡せる情報」「UI のクセ」「クライアント実装差」の影響を受けやすいので、なるべく役割を減らすのが安全です。
おすすめは次の 2 段階です。
- DHCPv6（Option 59）：まずは ipxe.efi（UEFI 版 iPXE）を 1 つだけ配布
- iPXE スクリプト：その後の処理（メニュー、OS別、カーネル引数、認証など）を HTTP で柔軟に制御
2 段階にすると、DHCP は「ブートファイルの場所を渡すだけ」になり、問題が起きたときに切り分けが一気に楽になります。まずは ipxe.efi が取れるか、次に start.ipxe が取れるか、という順番で確認できます。
start.ipxe の最小例（HTTP で次の処理へ）
あくまで雛形ですが、次のように「この後の本体スクリプトを別 URL に集約」すると運用が楽になります。
#!ipxe
# IPv6 環境で iPXE を動かす前提の最小例
# DHCPv6 を使う場合（環境により dhcp6 / dhcp のどちらが適切かは異なります）
dhcp6
set base-url http://[2001:db8::1]/ipxe
chain ${base-url}/menu.ipxe 本体（menu.ipxe）を更新するだけで、配布する OS や設定を一括で変えられます。Option 59 は変えずに済むため、DHCP の設定を触る頻度を減らせます。
よくある失敗と解決のコツ（現場で効くチェックリスト）
URL の書式ミス：IPv6 アドレスを [] で囲んでいない
Bootfile URL が http://2001:db8::1/start.ipxe のようになっていると、URL として解釈できず失敗します。必ず http://[2001:db8::1]/start.ipxe の形式にします。
TFTP を選んだが、サーバー側が IPv6 待受していない
TFTP は実装によって IPv6 が弱い場合があります。まずは HTTP に寄せるか、少なくとも「その TFTP サーバーが IPv6 で listen している」ことを確認します。ネットワーク機器側の ACL で UDP/69 が落ちているケースも多いので、切り分けの最初は HTTP をおすすめします。
ipxe.efi のアーキテクチャが合っていない（x64 と ARM、32bit/64bit など）
UEFI で起動する iPXE は、クライアントのアーキテクチャに合う .efi を配布する必要があります。x64 マシンに 32bit 用を渡すと起動しません。機種が混在している場合は、DHCP で配り分けるより、iPXE 起動後にスクリプトで分岐する方が運用は簡単です（最初の 1 本は標準を決める）。
UEFI Secure Boot が有効で、iPXE バイナリがブロックされる
Secure Boot が有効な環境では、署名されていない ipxe.efi が実行できず、何も起きない／すぐ戻る、という挙動になることがあります。検証時は一度 Secure Boot を無効化して切り分けるか、署名済みのブートローダーを使う構成を検討します。
そもそも DHCPv6 が届いていない（リレー/スイッチ設定の不備）
IPv6 のクライアントは L2 を跨ぐときに、DHCPv6 リレー（または L3 機器の設定）が必要になることがあります。DHCPv4 のリレー（IP helper）だけ設定して満足してしまい、DHCPv6 が届いていないケースは典型的です。Wireshark で DHCPv6 の SOLICIT/ADVERTISE が見えないなら、まずネットワーク経路を疑います。
IPv6 ならではの注意点：RA（ルータ広告）と DHCPv6 の役割分担を誤ると、Option 59 が配れない
IPv4 では「DHCP がアドレスもオプションも全部配る」構成が一般的でしたが、IPv6 では RA（Router Advertisement：ルータ広告） がアドレス設定に深く関わります。ここを誤ると、DHCPv6 側をどれだけ正しく設定しても、クライアントが DHCPv6 を要求しないため、Option 59（Bootfile URL）が届きません。
ざっくり言うと、IPv6 のクライアントは RA のフラグを見て「DHCPv6 を使うか／使わないか」を判断します。
| RA のフラグ | 意味 | 典型的な挙動 | ブートに与える影響 |
|---|---|---|---|
| M（Managed） | アドレスを DHCPv6 で管理（ステートフル） | DHCPv6 で IPv6 アドレスを取得 | Option 59 を配りやすい（DHCPv6 が必ず動く） |
| O（Other configuration） | アドレスは SLAAC、その他の情報を DHCPv6 で配る（ステートレス） | DNS などを DHCPv6 の Information-Request で取得 | ファームウェアによっては Option 59 を取りに来る／来ない差が出る |
ネットワークブート（UEFI PXE/HTTP Boot）の実装は機器差があるため、検証段階ではまず M フラグ（ステートフル DHCPv6）でシンプルに成立させるのが安全です。SLAAC 併用（O フラグ中心）にこだわるのは、Option 59 が確実に配れて動作確認が終わってからでも遅くありません。
Wireshark で「Option 59 が本当に返っているか」を確認する方法
DHCP の設定だけを眺めていても原因が分からないときは、パケットで事実確認するのが一番速いです。Wireshark なら、次のようなフィルタで DHCPv6 のやり取りを絞り込めます。
# DHCPv6 全般
dhcpv6
# Option 59 を含むパケットに絞る（環境により表現が異なることがあります）
dhcpv6.option.type == 59
クライアントから SOLICIT が出て、サーバーから ADVERTISE/REPLY が返り、その中に Option 59 が載っているかを確認します。ここで Option 59 が見えているなら、「DHCP は返している」ので、次は URL 到達性（HTTP/TFTP サーバー）や Secure Boot など、DHCP 以外の層に切り分けできます。
Windows Server 2012 R2 の DHCPv6 が厳しいときの現実的な選択肢
環境によっては、Windows DHCP の UI 制約や、DHCPv6 のブート関連オプションの扱いづらさがボトルネックになります。どうしてもハマる場合は、次の選択肢が現実的です。
- DHCPv6 を Linux 系に切り替える（ISC DHCP / Kea DHCP など）：Option 59 を素直に設定でき、ログや挙動も追いやすい
- ネットワーク機器（ルータ/スイッチ）の DHCPv6 機能を使う：Option 59 を GUI/CLI で設定できる機種がある
- ブートの“最初だけ”を IPv4 に寄せ、起動後に IPv6 を使う：要件が許すならトラブルは減る（ただし「IPv6 だけで完結」が必須なら不可）
特に iPXE は「ブートの最初の一歩さえ出れば、あとは HTTP で自由にできる」道具です。DHCP 実装の相性で無駄に消耗するより、最短で iPXE を起動できる経路を選ぶ方が、結果的に安定運用につながります。
まとめ
Windows Server 2012 R2 で iPXE を IPv6（DHCPv6）ブートしたいのに Option 67 相当が見当たらない問題は、DHCPv6 の設計思想を押さえると整理できます。DHCPv6 では「ファイル名だけ」ではなく、Option 59（Bootfile URL）で URL を丸ごと渡すのが基本です。
Windows DHCP では Option 59 が標準で見えないことがあるため、事前定義オプションとして追加し、スコープまたはサーバーに値を割り当てます。GUI が不安定な場合は PowerShell で定義・設定すると再現性が上がります。まずは ipxe.efi を 1 本だけ確実に配るところから始め、次に iPXE スクリプトを HTTP で引く 2 段階にすると、IPv6 環境でも切り分けと運用が楽になります。
コメント