Provided by: manpages-ja_0.5.0.0.20140515+dfsg-2_all 
名前
dhcpd.conf - dhcpd の設定ファイル
説明
dhcpd.conf は、Internet Software Consortium DHCP サーバ dhcpd の設定情報が書かれたファイル
です。
dhcpd.conf ファイルは自由形式の ASCII テキストファイルです。 dhcpd に組み込まれた再帰下降
型のパーザによって解釈されます。 このファイルには、整形の目的で余分なタブや改行を入れても
かまいません。 このファイルでは、キーワードの大文字小文字は区別されません。 コメントはファ
イルのどこにでも入れられます (クォートの内部を除く)。 コメントは # 文字で始まり、行末で終
わります。
このファイルは基本的には文 (statement) のリストからなります。 文は大きく二つのカテゴリに分
けられます。パラメータ文と宣言文です。
パラメータ文は、 なにかをどの様に行うか (例えば提供するリースの長さ)、 なにかを行うかどう
か (例えば素性のわからないクライアントにもアドレスを与えるかどうか)、 クライアントにどの様
なパラメータを与えるか (例えばゲートウェイとして 220.177.244.7)、 などを決めます。
宣言文は、 ネットワークのトポロジーを記述したり、 ネットワークのクライアントを記述したり、
クライアントに割り当て可能なアドレスを決めたり、 ひとまとまりのパラメータを宣言文のグルー
プに与えたりするために用います。 パラメータ文や宣言文のグループにおいては、 ある宣言文が依
存するパラメータ文は、 その宣言文よりも前に指定しなければなりません。
ネットワークトポロジーに関する宣言には shared-network 文と subnet 文があります。 サブネッ
トにあるクライアントがアドレスを動的に割り当ててもらう場合は、 subnet 宣言の内部に range
宣言文も必要になります。 静的にアドレスが割り当てられたクライアントや、 素性のわかっている
クライアントにのみアドレスを提供するような設定では、 このようなクライアントに対して host
宣言文が必要です。 特にサブネットに関連付けられていない宣言グループに 何らかのパラメータを
与えたい場合は、 group 宣言文が使えます。
サービスを受けるサブネットや、dhcp サーバが接続するサブネットには、 すべて subnet 宣言が必
要となります。これによって dhcpd は、 あるアドレスがそのサブネットにあることを認識するので
す。 subnet 宣言は、 そのサブネットに動的割り当てを受けるアドレスがなくても必要です。
場合によっては、一つの物理的なネットワークに上で 2 つ以上の IP サブネットが動作することが
あります。 例えば、組織のルールで 8 ビットのサブネットマスクを使っているとしましょう。 こ
のときある部門で、 一つの物理イーサネットネットワークに接続するノードが 254 を越えてしまっ
たら、 新しい物理ネットワークが追加できるまでは、 そのイーサネットで 8 ビットのサブネット
を 2 つ走らせなければならないでしょう。 このような場合には、 これらの 2 つのネットワークに
対する subnet 宣言は、 shared-network (共有ネットワーク) 宣言で囲うことができます。
サイトによっては、 ある部門のクライアントが 2 つ以上のサブネットに接続されていることもある
でしょう。 このときこれらのクライアントに共通のパラメータを与え、 かつ同じサブネットにいる
別の部門のクライアントには 違うパラメータを与えたいとしましょう。 host 宣言によって明示的
に宣言するクライアントでは、 これらを group 宣言によって囲って、 その部門に共通のパラメー
タを与えることができます。 アドレスが動的に割り当てられるクライアントでは、 今のところネッ
トワークトポロジーによる他には、 グループ単位でのパラメータ割り当てを行う方法はありませ
ん。
あるクライアントがブートする場合、 そのブートパラメータを決定するには、 まずそのクライアン
トの host 宣言が (存在すれば) 参照されます。 次にその host 宣言を囲っている group 宣言が
(存在すれば) 参照されます。 その次にはブートするクライアントが所属するサブネットの subnet
宣言が参照され、 さらにそのサブネットを囲っている shared-network 宣言が (存在すれば) 参照
されます。 最後に、すべての宣言の外部に置かれている、 トップレベルのパラメータが参照されま
す。
dhcpd がクライアントに対応する host 宣言を探すときには、 まずそのクライアントがブートしよ
うとしているサブネット (または共有ネットワーク) にマッチする fixed-address パラメータを含
む host 宣言を探します。 そのようなエントリがなければ、 fixed-address パラメータが含まれな
いエントリを探します。 そのようなエントリもなければ、 たとえそのクライアントのエントリが別
のサブネットや共有ネットワークにあっても、 dhcpd はそのクライアントのエントリが dhcpd.conf
ファイルには存在しないかのように動作します。
例
よくある dhcpd.conf ファイルの例を示します:
global parameters...
shared-network ISC-BIGGIE {
shared-network-specific parameters...
subnet 204.254.239.0 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.10 204.254.239.30;
}
subnet 204.254.239.32 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.42 204.254.239.62;
}
}
subnet 204.254.239.64 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.74 204.254.239.94;
}
group {
group-specific parameters...
host zappo.test.isc.org {
host-specific parameters...
}
host beppo.test.isc.org {
host-specific parameters...
}
host harpo.test.isc.org {
host-specific parameters...
}
}
Figure 1
ファイルの先頭にはグローバルなパラメータのための 場所があることにお気づきになったかと思い
ます。 ここでは組織のドメイン名、ネームサーバのアドレス (組織全体に共通のものがあれば) な
どを指定します。 従って、例えば次のようになるでしょう。
option domain-name "isc.org";
option domain-name-servers ns1.isc.org, ns2.isc.org;
Figure 2
Figure 2 にあるとおり、パラメータに与えるホストのアドレスは、 数値形式の IP アドレスではな
くドメイン名で与えてもかまいません。 与えられたホスト名が 1 つ以上の IP アドレスに解決され
る (例えばホストがイーサネットインターフェースを 2 つ持っているなど) 場合には、クライアン
トにはすべてのアドレスが渡されます。
Figure 1 からわかるとおり、shared-network 文も subnet 文もパラメータを取ることができます。
ここで共有ネットワーク ISC-BIGGIE は部門 (例えば経理部門) 全体をサポートしているとしましょ
う。 経理部門には自前のドメインがあるとすると、 shared-network 専用のパラメータとして以下
を与えるべきでしょう。
option domain-name "accounting.isc.org";
すると shared-network 宣言の内部にある subnet 宣言では、 domain-name オプションは単なる
"isc.org" ではなく "accounting.isc.org" になります。
Figure 1 のように subnet に固有のパラメータを与えたいのは、 当然ながら、サブネットはそれぞ
れ違ったルータを必要とするからです。 したがって最初のサブネットには、 例えば以下のような文
が置かれることになるでしょう。
option routers 204.254.239.1;
ここではアドレスは数値で指定されています。 これは必須ではありません。 もしルータの各イン
ターフェースが別々のドメイン名を持っているなら、 そのインターフェースの指定には、数値でな
くドメイン名を用いても全くかまいません。 しかしながら、多くの場合ルータの IP アドレスそれ
ぞれには 一つの同じドメイン名がつけられているでしょうから、 ここでその名前を用いるのは適切
ではないでしょう。
Figure 1 では、group 文も使われており、 3 つのホスト (zappo, beppo, harpo) に共通のパラ
メータをあたえています。 おわかりのように、これらのホストはすべて test.isc.org ドメインに
属しています。 したがってこれらのホストには、 グループ固有のパラメータとしてドメイン名を上
書きするかたちで 与えるのが良いでしょう。
option domain-name "test.isc.org";
また、所属するドメイン名から想像できるように、 これらはおそらくテスト用のマシンでしょう。
DHCP 貸し出し機構をテストする場合には、 貸し出しの期限をデフォルトよりは少々短くしておくの
が良いでしょう。
max-lease-time 120;
default-lease-time 120;
これまでのところで、option キーワードによって始まるパラメータと、 そうでないパラメータとが
あることにお気づきになったでしょうか。 option キーワードで始まるパラメータは、 実際の DHCP
オプションに関連したものです。 そうでないものは、 DHCP サーバの動作を制御するもの (例えば
dhcpd が提供する貸し出しの期限など) か、 DHCP プロトコルでは提供されていないクライアント用
のパラメータ (例えばサーバ名やファイル名) です。
Figure 1 では、各ホストは「ホスト固有のパラメータ」を持っていました。 これらには例え
ば、hostname オプション、 取得するするファイル (filename パラメータ)、 ファイルを取得する
ホスト (next-server パラメータ) などが含まれます。 一般的には、パラメータを指定できる場所
にはどんなパラメータでも指定でき、 そのパラメータは置かれた場所のスコープにしたがって適用
されます。
NCD の X 端末がたくさんあるようなサイトを想像してください。 これらの端末にはさまざまなモデ
ルがあるので、 それぞれのモデルに対して別々のブートファイルを指定したいとします。 これを行
う一つの方法は、 各端末に host 宣言をさせ、それらをモデルごとに group 化することです。
group {
filename "Xncd19r";
next-server ncd-booter;
host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
}
group {
filename "Xncd19c";
next-server ncd-booter;
host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
}
group {
filename "XncdHMX";
next-server ncd-booter;
host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
}
リファレンス: 宣言文
shared-network 文
shared-network name {
[ parameters ]
[ declarations ]
}
shared-network 文は、複数の IP サブネットが実際には 一つの物理ネットワークを共有しているこ
とを DHCP サーバに伝えるために用います。 共有ネットワーク内にあるサブネットは、 shared-
network 文の内部で宣言するようにすべきです。 shared-network 文の内部で指定されたパラメータ
は、 それらのサブネットでブートしたクライアントによって用いられます (ただしそのパラメータ
がサブネットやホストレベルで上書きされた場合を除く)。 共有ネットワークに属するサブネットに
動的割り当て可能なアドレスがあると、 これらのアドレスは共有ネットワーク用の場所に共通に
プールされ、 必要に応じてクライアントに提供されます。 あるクライアントが、(共有ネットワー
クに属する) どのサブネットからブートさせるべきかを識別する方法はありません。
name には共通ネットワークの名前を指定しておきましょう。 この名前はデバッグメッセージの出力
時に用いられるので、 その共通ネットワークの認識に役立ちます。 名前にはドメイン名として有効
な書式 (ただしドメイン名としては用いられない) が使えます。 あるいはクォートすればどんな名
前でも使えます。
subnet 文
subnet subnet-number netmask netmask {
[ parameters ]
[ declarations ]
}
subnet 文は、 ある IP アドレスが特定のサブネットに属しているかどうか判断するための情報を
dhcpd に与えるために用います。 またサブネット固有のパラメータを指定したり、 そのサブネット
でブートしたクライアントに 動的割り当て可能なアドレスを指定するためにも利用されます。 後者
のようなアドレスは range 宣言で指定されます。
subnet-number には IP アドレスか、 あるいは宣言するサブネットの IP 番号に解決されるドメイ
ン名を与えます。 netmask には IP アドレスか、 あるいは宣言するサブネットのサブネットマスク
に解決されるドメイン名を与えます。 サブネット番号とネットマスクとを与えると、 ある与えられ
た IP 番号が そのサブネットに属しているかどうかを判断できるようになります。
ネットマスクはすべての subnet 宣言に必要ですが、 あるサイトの内部で用いているサブネットマ
スクに複数の種類がある場合は、 subnet-mask オプション文を各 subnet 宣言の内部で用いて、 適
切なサブネットマスクを設定することもしておくべきです。 なぜかというと、subnet-mask オプ
ション文は、 subnet 文で宣言されたサブネットマスクより優先されるからです。
range 文
range [ dynamic-bootp ] low-address [ high-address];
動的に割り当てられるアドレスを含むサブネットでは、 少なくとも range 文を一つ指定しなければ
なりません。 range 文には IP アドレスの範囲の最小値・最大値を与えます。 その範囲に入る IP
アドレスのすべては、 range 文が宣言されたサブネットの中に入っている必要があります。 指定し
た範囲のアドレスを DHCP クライアントと BOOTP クライアントの両方に割り当てて良い場合は、
dynamic-bootp フラグを指定します。 アドレス 1 つだけを割り当てる場合は、 high-address は省
略できます。
host 文
host hostname {
[ parameters ]
[ declarations ]
}
サービス対象となる BOOTP クライアントには、それぞれ host が最低ひとつづつ必要になります。
DHCP クライアントに対しても host 文は指定できますが、 素性のわからないホストにはブートを許
可しないような設定でなければ、 指定しなくてもかまいません。
ある DHCP クライアントや BOOTP クライアントを、 複数のサブネットにおいて固定アドレスでブー
トさせたい場合には、 fixed-address パラメータに複数のアドレスを指定するか、 あるいは host
文を複数指定します。
クライアント固有のブートパラメータを、 接続されたネットワークによって代えなければならない
場合には、 host 文を複数用いるべきです。
可能な場合にはクライアントを固定アドレスでブートさせたいが、 それができなければ動的なアド
レスを割り当てたい、という場合には、 host 文の内部では fixed-address 文を指定しないように
します。
host 宣言を実際の DHCP クライアントや BOOTP クライアントにマッチさせる際には、 host 宣言の
内部で指定された dhcp-client-identifier オプションが、 クライアントが渡してきた識別子と
マッチするかを確認します。 もし host 宣言の内部に dhcp-client-identifier がなかったり、 ク
ライアントがこの識別子を渡してこなかった場合には、 host 宣言の内部で指定された hardware パ
ラメータが、 クライアントが渡してきたハードウェアアドレスとマッチするかを確認します。
BOOTP クライアントは通常 dhcp-client-identifier を渡さないので、 BOOTP プロトコルでブート
させるクライアントに対しては、 必ずハードウェアアドレスを用いなければなりません。
group 文
group {
[ parameters ]
[ declarations ]
}
group 文は、なんらかのパラメータを宣言のグループに適用するために用います。 ホスト、共有
ネットワーク、サブネット等をまとめたり、 あるいは他のグループをまとめることもできます。
リファレンス: ALLOW と DENY
allow 文と deny 文を使うと、 いろいろな要求に対する dhcpd の振る舞いを制御できます。
unknown-clients キーワード
allow unknown-clients;
deny unknown-clients;
素性のわからない (unkown な) クライアントに動的にアドレスを割り当てるかどうかを dhcpd に指
示します。 デフォルトでは unkown なクライアントへの動的アドレス割り当ては allow (許可) さ
れています。
bootp キーワード
allow bootp;
deny bootp;
bootp フラグは、 bootp クエリ (問い合わせ) に答えるかどうかを dhcpd に指示します。 デフォ
ルトでは bootp クエリは allow (許可) されています。
booting キーワード
allow booting;
deny booting;
booting フラグは、 特定のクライアントからのクエリに答えるかどうかを dhcpd に指示します。
このキーワードは、host 宣言の内部に置かれた場合にのみ意味を持ちます。 デフォルトでは
booting は allow (許可) されています。 しかしこれを特定のクライアントに対して無効にする
と、 そのクライアントはこの DHCP サーバからはアドレスを取得できなくなります。
リファレンス: パラメータ
default-lease-time 文
default-lease-time time;
time は秒単位の時間で、 貸し出しを要求しているクライアントが特に期限を求めなければ、 この
時間が貸し出し時間になります。
max-lease-time 文
max-lease-time time;
time は秒単位の時間で、 貸し出しを要求しているクライアントが期限を求めた場合に、 割り当て
可能な最大の貸出時間です。
hardware 文
hardware hardware-type hardware-address;
BOOTP クライアントが認識されるためには、 host 文の内部で hardware 指定によってそのネット
ワークハードウェアアドレスが 指定されていなければなりません。 hardware-type は物理ハード
ウェアインターフェースの形式名です。 現在のところは ethernet と token-ring だけが認識され
ます (fddi などのハードウェア型も認識されると良いのでしょうが)。 hardware-address は 16 進
オクテット (0 から ff までの数値) のセットで、 区切りはコロンです。 hardware 文は DHCP ク
ライアントにも用いることができます。
filename 文
filename "filename";
filename 文はクライアントにロードさせる初期ブートファイルの指定に使います。 filename はク
ライアントが使うであろうファイル転送プロトコルで 認識されるファイル名でなければなりませ
ん。
server-name 文
server-name "name";
server-name 文はクライアントに接続中のサーバの名前を伝えるために用います。 name はクライア
ントに渡される名前です。
next-server 文
next-server server-name;
next-server 文は初期ブートファイル (filename 文で指定したもの) をロードするサーバのホスト
アドレスを指定するために使います。 server-name は数値の IP アドレスかドメイン名です。 接続
してきたクライアントに対して与えるべき next-server パラメータがなければ、DHCP サーバの IP
アドレスが用いられます。
fixed-address 文
fixed-address address [, address ... ];
fixed-address 文は、あるクライアントに対して一つまたは複数の IP アドレスを割り当てるために
用います。 host 宣言の内部でのみ用いられます。 複数のアドレスが指定された場合には、 そのク
ライアントがブートするネットワークに所属するアドレスが割り当てられます。 クライアントが
ブートするネットワークに属するアドレスが fixed-address 文にない場合は、そのクライアントは
その fixed-address 文が含まれる host 宣言にマッチしないことになります。各 address は IP ア
ドレスか、 一つ (または複数) の IP アドレスに解決されるドメイン名です。
dynamic-bootp-lease-cutoff 文
dynamic-bootp-lease-cutoff date;
dynamic-bootp-lease-cutoff 文は、動的に割り当てた BOOTP クライアントへのすべての貸し出しを
終了させる時刻を設定します。 BOOTP クライアントは貸し出しを更新する機構を持たず、 また貸し
出しがいつ期限切れになるかを知らないので、 デフォルトでは dhcpd は BOOTP クライアントへは
無期限の貸し出しを行います。 しかし、ある場合には BOOTP の貸し出し停止に意味があるかもしれ
ません。 例えば学期の最後や、夜中のある時間になると施設が閉まって、 すべてのマシンが電源停
止になるような場合などです。
date は割り当てられた BOOTP 貸し出しのすべてが終了する時刻です。 date は以下の書式で指定し
ます。
W YYYY/MM/DD HH:MM:SS
W は曜日を数値で指定したもので、0 (日曜日) から 6 (土曜日) までです。 YYYY は年で、世紀の
桁も指定します。 MM は月を数値で指定したもので、 1 から 12 マデです。 DD は月内日を数値で
指定したもので、 1 から数えます。 HH は時間で、0 から 23 までです。 次の MM は分で、SS は
秒です。 時刻は常に協定世界時 (UTC) で指定します (地方時ではありません)。
dynamic-bootp-lease-length 文
dynamic-bootp-lease-length length;
dynamic-bootp-lease-length 文は BOOTP クライアントへの動的割り当ての貸し出し期間の設定に用
います。 サイトによっては、一度アドレスを貸し出したクライアントから 一定の間 BOOTP や DHCP
での再割り当て要求がなければ、 そのアドレスはもう使われない、とみなすことが可能かもしれま
せん。 貸出機関は length に秒単位で指定します。 その期間のうちにクライアントが BOOTP を用
いて再ブートすると、 貸し出し期間も length にリセットされます。 したがって頻繁にブートする
BOOTP クライアントは、 割り当てられたアドレスをずっと保持し続けます。 言うまでもありません
が、このパラメータは細心の注意を払って決めてください。
get-lease-hostnames 文
get-lease-hostnames flag;
get-lease-hostnames 文は、貸し出し用にプールされている IP アドレスのドメイン名を引き、 そ
のアドレスを DHCP hostname オプションに用いるかどうかを dhcpd に伝えるために用います。
flag が真ならば、現在のスコープにあるすべてのアドレスに対して この名前引きが実行されます。
デフォルトでは flag は偽で、名前引きは行われません。
use-host-decl-names 文
use-host-decl-names flag;
use-host-decl-names パラメータがその置かれたスコープで真 (true) だと、 そのスコープに置か
れたすべての host 宣言において、 宣言に使われた名前がホスト名としてクライアントに渡されま
す。 したがって例えば、
group {
use-host-decl-names on;
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
}
}
は次と全く同じになります。
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
option host-name "joe";
}
host 宣言の内部に置かれた option host-name 文は、宣言に用いられた名前よりも優先されます。
authoritative 文
authoritative;
not authoritative;
通常 DHCP サーバは、あるネットワークセグメントの設定情報は 正しくかつ信頼できるとみなして
います。 よってクライアントがあるネットワークセグメントの IP アドレスを要求したとき、 サー
バがそれがそのセグメントでは正しくないことを知っていると、 サーバは DHCPNAK メッセージを返
します。 するとクライアントはその IP アドレスを忘れ、 新しいアドレスを取得しようとします。
DHCP サーバがネットワーク管理者ではない人間によって設定され、 よってこのレベルの権威を持た
せたくない場合には、 設定ファイルの適切なスコープに "not authoritative" という文を入れてお
くと良いでしょう。
通常は、 not authoritative をファイルのトップレベルに書いておけば十分です。 しかし、ある
ネットワークに対しては権威を持たせ、 別のネットワークに対しては持たせないように DHCP サー
バを設定したい場合には、 ネットワークセグメント単位で authority を宣言するほうが良いでしょ
う。
authority が意味を持つスコープは、物理ネットワークセグメントの単位です。 すなわち shared-
network 文か、 shared-network 文の内部にはない subnet 文です。 共有ネットワークに属してい
るサブネットの一部のみに対して サーバに権威を持たせても意味はありません。 また一部の host
宣言に対してのみサーバに権威を持たせても、 同じく意味はありません。
use-lease-addr-for-default-route 文
use-lease-addr-for-default-route flag;
use-lease-addr-for-default-route パラメータがその置かれたスコープで真だと、 routers オプ
ションで指定した値を送る (あるいは値を全く送らない) 代わりに、割り当てようとしている IP ア
ドレスをクライアントに送ります。 こうすると Win95 マシンはすべての IP アドレスを ARP する
ようになり、 使っているルータが proxy ARP に設定されている場合には役に立ちます。
use-lease-addr-for-default-route が有効になっていて、 option routes 文も同じスコープにある
場合には、 routes オプションが優先されます。 この理由は、この機能を使いたい局面では、 たく
さんある Windows 95 マシンすべてにはこの機能を有効にし、 その他数台のマシンではこれを無効
にしたくなるだろうからです。 不幸にして状況が逆の場合は、 このフラグは用いないほうがたぶん
良いでしょう。
always-reply-rfc1048 文
always-reply-rfc1048 flag;
BOOTP クライアントの中には、受信には RFC1048 形式のものを期待するのに、 送信では RFC1048
を守らないものがあります。 あるクライアントがこの問題を抱えている場合には、 そのクライアン
トは設定したオプションを取得せず、 また BOOTREQUEST するたびに サーバのログに "(non-
rfc1048)" というメッセージが現れます。
このようなクライアントに rfc1048 オプションを送信したい場合は、 そのクライアントの host 宣
言に always-reply-rfc1048 を設定します。すると DHCP サーバは RFC-1048 形式のベンダーオプ
ションフィールドを用いて応答します。 このフラグはどのスコープにも設定でき、 そのスコープで
カバーされるすべてのクライアントに適用されます。
server-identifier 文
server-identifier hostname;
server-identifier 文は、それが置かれたスコープ内において、 DHCP サーバ識別子オプションで送
られる値を定義するために用います。 指定する値は DHCP サーバの IP アドレスでなければなら
ず、 そのスコープにおいてサービスを受けるすべてのクライアントから 到達可能でなければなりま
せん。
server-identifier 文の使用は勧められません。 唯一の利用局面は、デフォルトで送られる値が間
違っている場合に、 その値を別のものに変更する場合だけです。 デフォルトの値は、要求が到達し
た物理ネットワークインターフェースに 関連付けられた最初の IP アドレスです。
server-identifier 文が必要になるのは、物理インターフェースに複数の IP アドレスがついてい
て、 デフォルトで送られるアドレスが、 サービスを受ける一部または全部のクライアントにとって
適切ではない場合です。 他にあり得る例としては、 DHCP サーバの IP アドレスを一貫させるため
に IP エイリアスが定義されており、 クライアントがサーバいん接続する際にはこの IP アドレス
を用いるのが望ましい場合があります。
リファレンス: オプション文
DHCP オプション文はマニュアルページ dhcp-options(5) で説明されています。
関連項目
dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
著者
dhcpd(8) は Ted Lemon <mellon@vix.com> が Vixie Labs との契約のもとに書きました。 このプロ
ジェクトの資金は、 Internet Software Corporation によって提供されました。 Internet
Software Consortium の情報は http://www.isc.org/isc にあります。
dhcpd.conf(5)