Windows Server 2016 で UEFI の HTTP/HTTPS Boot を構成したいとき、IPv4 では「Vendor Class ID」「Bootfile Name」を DHCP オプションで配れば動くのに、DHCPv6 になると同じ発想で設定できずに行き詰まりがちです。この記事では、DHCPv6 での相当オプション（Option 16 / Option 59）を Windows DHCP に「定義済みオプション」として追加し、IPv6 スコープへ反映する具体手順と、GUI で消える・反映されないなどの落とし穴をまとめます。
なぜ IPv4 と同じ手順で DHCPv6 がうまくいかないのか
Windows Server の DHCP 管理コンソールは、IPv4（DHCPv4）向けには PXE/UEFI Boot を連想しやすい項目（Vendor Class、Bootfile Name など）が見つけやすい一方、IPv6（DHCPv6）側は「最初から同名の項目が GUI に並んでいない」ことがあります。結果として、IPv4 と同じ “設定の探し方” をしても、DHCPv6 のスコープ側で目的の項目に辿り着けず、HTTP/HTTPS Boot が成立しません。
DHCPv6 でもブートに必要な情報を配布する仕組みはあります。ただし、Windows Server 2016 の GUI では、まずオプション定義（Option Definition）を自分で作り、それからスコープオプション（Option Value）として値を設定する、という二段構えになるケースがあります。
結論：DHCPv6 では Option 16 と Option 59 を「定義済みオプション」として追加して使う
IPv4 における「Vendor Class ID」「Bootfile Name」に相当するものとして、DHCPv6 側では次の 2 つを押さえておくのが実務的です。
| 目的 | DHCPv4（IPv4）での考え方 | DHCPv6（IPv6）での相当 | ポイント |
|---|---|---|---|
| クライアント種別の判別（UEFI/HTTP Boot 等） | Vendor Class ID | Option Code 16：Vendor Class ID（ベンダークラス識別子） | 値は端末・ファームウェア実装に依存。まずは実際に端末が送ってくる値を確認する。 |
| ブート先の指定 | Bootfile Name | Option Code 59：Bootfile Name 相当（HTTP Boot では Bootfile URL として扱われることが多い） | HTTP/HTTPS なので “ファイル名” ではなく URL で配る設計になりやすい。 |
重要なのは、DHCPv6 ではこれらが最初から GUI 上に見えているとは限らない点です。見えない場合は、DHCP の「定義済みオプション（Predefined Options）」に自分で追加し、スコープで有効化して値を入れます。
DHCPv6 の「定義」と「スコープ設定」を分けて理解する
Windows DHCP でつまずきやすいのが、「オプションを追加したのに設定できない」「設定したはずなのに配られない」という状態です。原因の多くは、次の 2 つを混同していることにあります。
| 区分 | 何をする場所か | 例 | つまずきポイント |
|---|---|---|---|
| 定義済みオプション（Option Definition） | 「Option Code とデータ型と名前」を DHCP サーバーに登録する | Option 16 / Option 59 を新規定義 | ここを作らないと、スコープ側で選択肢に出てこない |
| スコープオプション（Option Value） | 定義済みオプションに対して、スコープごとの値を設定する | Option 59 に https://… を入れる | 値の形式（文字列/バイナリ/複数値）を誤ると配布されても解釈されない |
この二段階を意識すると、GUI で項目が出ない場合でも、やるべき作業が明確になります。
Windows Server 2016 DHCP（GUI）で Option 16 / 59 を追加する手順
ここでは「DHCP 管理ツール（dhcpmgmt.msc）」を使い、IPv6 側に必要なオプションを見える化して、スコープへ設定する流れを具体化します。日本語 UI 名称は環境により微妙に差がありますが、構造は同じです。
定義済みオプションに Option 16 / 59 を追加する
- DHCP 管理ツールを開き、対象の DHCP サーバーを展開します。
- IPv6 のツリーを展開し、「定義済みオプション」（または同等の項目）を開きます。
- 右クリックして 「新しいオプションを定義」 を選びます。
- 以下を目安に、まず Option 16 を追加します。
- Option Code：16
- 名前：Vendor Class ID（自分が分かる名前で可）
- データ型：（環境に合わせて）文字列またはバイナリ
※端末が期待する形式に合わせる必要があります。どちらか迷う場合は、後述のパケット確認で実際のやり取りを見て決めるのが安全です。 - 説明：UEFI HTTP/HTTPS Boot 判別用、など
- 同様に Option 59 を追加します。
- Option Code：59
- 名前：Bootfile URL（または Bootfile Name 相当）
- データ型：文字列（URL を入れる想定）
- 説明：UEFI HTTP/HTTPS Boot の取得先 URL
この時点で重要なのは、「Option 16 / 59 を作った」だけで、まだ配布はされていないことです。次のステップでスコープへ値を入れます。
IPv6 スコープオプションで有効化し、値を設定する
- 対象の IPv6 スコープ を展開します。
- 「スコープ オプション」 を開き、右クリックして 「オプションの構成」 を選びます。
- 先ほど追加した Option 16 / 59 が一覧に出てくるのでチェックを入れます。
- それぞれの値を設定します。設定例は次の通りです。
- Option 16（Vendor Class ID）：端末が送ってくるベンダークラスに合わせる（例：HTTP Boot を示す文字列を送る実装もあれば、別の値のこともあります）
- Option 59（Bootfile URL）：
https://boot.example.local/uefi/bootx64.efiのように、UEFI が取得できる URL を指定
ここまでが基本形です。IPv4 の「ベンダークラスで分岐して Bootfile Name を変える」運用をしていた場合、DHCPv6 でも同じ発想で分岐したくなりますが、まずは単一のスコープで最小構成（Option 59 が確実に配られ、端末が確実に取得できる）を作ってから、分岐設計に進むのがトラブルを減らします。
設定値の作り方：Vendor Class と Bootfile URL を “決め打ち” しない
UEFI HTTP/HTTPS Boot 周りは、同じ「UEFI 対応 NIC/ファームウェア」でも、DHCP の要求オプションや Vendor Class の中身が微妙に異なることがあります。そこで、最初から値を決め打ちせず、次の順で詰めると失敗しづらいです。
ベンダークラス（Option 16）は「端末が実際に送る値」を起点にする
- “よくある文字列” を入れても、端末側がその条件で分岐しないなら意味がありません。
- 同じメーカーでも機種や UEFI バージョンで挙動が変わることがあります。
- 最初は Option 16 を使った高度な分岐は後回しにし、Option 59 の配布と取得が成立するかを先に確認します。
Bootfile URL（Option 59）は「UEFI が到達できる URL」にする
HTTP/HTTPS Boot は、TFTP でファイル名を渡すのとは違い、UEFI が URL として解釈できる必要があります。運用では次の点が重要になります。
- 名前解決（DNS）：UEFI 側が引ける名前であること（検証段階では IP 直指定の URL で切り分けるのも有効）
- アクセス制御：UEFI からの GET をブロックしない（IP 制限や認証があると失敗しやすい）
- ファイル配置：UEFI が取得する .efi を正しいパスへ置く
- 可用性：冗長化するなら DNS やロードバランサ、コンテンツ配布の設計も考える
GUI から Option 59 が消える／再起動後に HTTP Boot が失敗する場合の見方
現場で厄介なのが、いったん定義・設定できたはずの Option 59 が、DHCP サービス再起動後に GUI から見えなくなる、あるいは IPv6 HTTP Boot 自体が失敗し始めるケースです。相談事例としては、GUI では消えるのに、netsh（dhcp server v6）では Option 59 自体が存在するように見える、という状況が報告されています。
このパターンでは、次のように切り分けると原因に近づきます。
まず確認したいポイント
| 確認項目 | 狙い | 見るべき結果 |
|---|---|---|
| Option 定義が残っているか | 定義そのものが消えたのか、GUI 表示だけの問題かを切り分ける | 定義が残っていれば GUI の表示・反映問題の可能性が上がる |
| スコープに Option 値が残っているか | 配布されるべき値が設定として残っているか | 残っていれば “配布はできているのに取得できない” 方向へ切り分け |
| クライアントが DHCPv6 を要求しているか | UEFI が DHCPv6 を叩いているか、別経路（SLAAC のみ等）になっていないか | Solicit/Request が見えないならネットワーク側（RA 設計等）を疑う |
| DHCPv6 応答に Option 59 が乗っているか | サーバーの応答自体に Option 59 が含まれているか | Reply に Option 59 がないなら DHCP 側の設定/反映が原因 |
GUI 不具合・制限の可能性が高いときの実務的な対処
- GUI 表示だけを信じない：GUI で消えて見えても、実体（定義・値）が残っていることがあります。コマンドで定義/値を確認し、実際に配布されているかはパケットで判断します。
- 設定変更の履歴を残す：DHCP のエクスポート（バックアップ）や、設定内容のテキスト化（実行したコマンドやスクリーンショット）を残し、再構築を短時間でできるようにします。
- パッチ適用・バージョン検討：Windows Server 2016 の DHCP は長期運用されがちですが、HTTP Boot のような比較的新しめの使い方は周辺不具合の影響を受けることがあります。検証環境が用意できるなら、更新適用状況や後継バージョン（2019/2022 等）での再現性も確認すると安全です。
コマンドで確認する：Option 59 が “存在するのに見えない” を切り分ける
GUI に依存せず、定義や値の状態を確認するための考え方をまとめます。ここでは PowerShell と netsh の両方を触れますが、目的は「定義が残っているか」「値が残っているか」「意図通りの値が入っているか」の確認です。
PowerShell で DHCPv6 のオプション定義と値を確認する
DHCP サーバー管理用の PowerShell コマンドレットを使うと、GUI 表示に左右されず状態を追えます。
# オプション定義（Option 16 / 59）が存在するかを確認
Get-DhcpServerv6OptionDefinition | Where-Object { $_.OptionId -in 16,59 } | Format-List
# スコープ側のオプション値を確認（スコープ識別子は環境に合わせて指定）
# 例：特定スコープの値を取得（コマンドの引数は Get-Help で確認）
Get-DhcpServerv6OptionValue -Allコマンドレットは環境（OS ビルド、RSAT の有無、モジュール）で表示形式が異なることがあります。大事なのは “OptionId 59 の値として URL が残っているか” を確認することです。
netsh（dhcp server v6）で Option の存在を確認する
相談事例にもある通り、GUI では消えても netsh 側で見える場合があります。実務では「netsh で定義が見える＝内部的には残っている可能性がある」という判断材料になります。
# 例：DHCPv6 のコンテキストに入って確認する（実際のサブコマンドは help で確認）
netsh
netsh> dhcp server
netsh dhcp server> v6
netsh dhcp server v6> ?ここで “Option 59 が一覧に出る/出ない”“設定済みの値が表示できる/できない” を確認し、GUI の表示問題なのか、設定そのものが欠落しているのかを切り分けます。
UEFI HTTP/HTTPS Boot は DHCP だけで完結しない：IIS / HTTPS 側の落とし穴
DHCPv6 の Option 59 で URL を配れたとしても、UEFI がその URL へ到達できなければブートは失敗します。特に HTTPS を使う場合、ネットワークよりもIIS 側（Web サーバー側）の設定や証明書/TLS 周りで詰まることが多いです。
HTTPS で失敗しやすい代表例
- 証明書の信頼：UEFI ファームウェアがそのサーバー証明書（または発行 CA）を信頼できず、TLS ハンドシェイクで止まる
- TLS バージョン／暗号スイート：UEFI 側の実装が対応していない組み合わせで交渉に失敗する
- SNI や名前解決：UEFI の HTTPS 実装が SNI を前提とした設定と相性が悪い／CN/SAN と接続先名が一致しない
- リダイレクト：HTTP→HTTPS リダイレクトや別パスへの 302 など、UEFI が追従できず失敗する
切り分けのコツ
| 状況 | まずやること | 判断材料 |
|---|---|---|
| DHCP の応答は正しそうだがブートしない | いったん HTTP（非 TLS）で成功するか検証する | HTTP で成功するなら、HTTPS（証明書/TLS）側が主原因 |
| HTTPS にすると急に失敗する | UEFI 画面のエラー表示、Web サーバーのアクセスログ/エラーログを確認 | そもそも GET が来ていないなら TLS 交渉以前の問題の可能性 |
| 一部端末だけ失敗する | 端末ごとの UEFI 実装差を疑い、同一 URL で再現性を取る | 機種依存なら DHCP ではなく UEFI 実装や証明書信頼の差 |
つまり、DHCPv6 の Option 59 は “入口” に過ぎません。入口が整ったら、Web サーバー側（IIS/HTTPS）の設定、コンテンツ配置、証明書の信頼まで含めて一気通貫で確認する必要があります。
運用で失敗しないための設計メモ
まずは最小構成で成功体験を作る
- IPv6 スコープに Option 59 を入れ、単一の URL で 1 台でも確実に起動させる
- その後に、端末差分（UEFI 実装差）や HTTPS 化、分岐（機種/用途）へ広げる
“URL の正しさ” は人間のブラウザではなく UEFI で判断する
PC 上のブラウザで開ける URL でも、UEFI 実装が同じように開けるとは限りません。HTTP ヘッダーや TLS の細かい差で失敗することがあります。検証時は、UEFI のブートログ表示、Web サーバーのアクセスログ、そして DHCPv6 のパケット（Option 59 が実際に配布されているか）をセットで追うのが確実です。
GUI 依存を減らし、再現性のある設定方法を用意する
- Option 定義やスコープ値は、可能なら PowerShell で記録しておく（手順書＋コマンドの形にする）
- DHCP のバックアップ/エクスポートを運用に組み込む
- GUI の表示不具合が疑われる場合ほど、コマンドとパケットで事実確認する
まとめ：DHCPv6 で “IPv4 と同じ発想” を実現するには、Option 16/59 を自分で用意する
Windows Server 2016 の DHCPv6 で UEFI の HTTP/HTTPS Boot を動かすうえで、押さえるべきポイントは次の通りです。
- DHCPv6 では IPv4 と同名の GUI 項目が最初から見えないことがある
- その場合は 「定義済みオプション」として Option 16（Vendor Class ID）と Option 59（Bootfile URL）を手動追加してから、スコープで値を設定する
- Option 59 が GUI から消える／再起動で失敗するなどは、GUI 表示や反映の不具合・制限の可能性があるため、コマンドとパケットで事実確認する
- HTTPS Boot は DHCP だけで完結せず、IIS/証明書/TLS 側の設計・切り分けが成功の鍵になる
まずは Option 59 を確実に配布し、端末が URL を取りに行ける状態を作ることが最短ルートです。そこから Vendor Class（Option 16）を使った分岐や HTTPS 化を積み上げていくと、再現性のある HTTP/HTTPS Boot 環境に近づけます。
コメント