DHCP
概要
RFC 2131 で規定されている。以下の二つのコンポーネントから構成される。
DHCP サーバからホストへ、ホスト特有の設定値を配信するためのプロトコル
ホストにネットワークアドレスを割り振るメカニズム
The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.
https://tools.ietf.org/html/rfc2131
DHCP サーバ/クライアントソフトは大抵の OS が備えている。サーバ用ソフトについては、ブロードバンドルータにも大抵備えられていて、そのおかげで PC をルータへ繋ぐだけでインターネットアクセスが行える。
DHCP は、一般的なサーバクライアントモデルで動作する。RFC 上では、サーバ/クライアントは以下のように定義される。
DHCP サーバ
DHCP を通して初期パラメータを提供するホスト
DHCP クライアント
初期パラメータをリクエストするホスト
ネット上には多様なホストが存在し、その全てがランダムに DHCP リクエストに答えられてしまうと、信頼性が下がる。
IP の設定項目はたくさんあり、IP を利用可能なネットワーク機器も多様に存在する。そのため、IP の値が正しいか予測したり、それがデフォルト値であるかどうかを正しく判断することも難しい。分散型のアドレス割り当てでは、ネットワークアドレスの重複を防ぐのが難しい。そのため、DHCP サーバはそのホストの管理者が明示的に設定しない限り DHCP サーバとして動作すべきでない。
IP アドレス割り当てのために、以下の 3 つのメカニズムをサポートしている。
自動割り当て : 永続的な IP アドレスをクライアントに割り当てる
動的割り当て : 限られた時間のみ IP アドレスをクライアントに割り当てる
手動割り当て : ネットワーク管理者によってクアライアントに IP アドレスを割り当てる
動的割り当てだけが、いらなくなった IP アドレスを自動的に使いまわすことができる。
DHCP メッセージのフォーマットには BOOTP メッセージをベースにしている。BOOTP リレーエージェントを利用することで、DHCP サーバが物理的な各ネットワークセグメントになくてすむようになっている。
DHCP はそのクライアントに、インターネットホスト要求を定義した RFC 群 に定義された設定値を提供するために設計されている。クライアントはDHCP を介して値を取得したあと、インターネット上の他のホストとパケットを交換できる必要がある。TCP/IP スタックの設定値は RFC 2131 の Appendix にリストアップされている。ただし、これらすべての値で初期化される必要はなく、クライアントもしくはサブネットに固有のパラメータのみで通信を行うこともできる。
DHCP は IP プロトコルに直接関連しないクライアントの設定も許す。また、新しく設定されたクライアントの登録を DNS にアドレスしない。
BOOTP と DHCP のやりとり
DHCP と BOOTP の違い
クライアントにネットワークアドレスを期限付きで割り当て可能なメカニズムを定義しており、それを異なるクライアントに再度割り当てることもできる
クライアントの動作に必要な全ての IP 設定値を取得するためのメカニズムを提供している
vender extensions フィールドが DHCP では options フィールドになっている
code:shell
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128) |
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+
table:DHCPメッセージ
フィールド オクテット 概要
op 1 メッセージタイプ
htype 1 ハードウェアアドレスタイプ (RFC 1700)
hlen 1 ハードウェアアドレス長
hops 1 クライアントは0。リレーエージェントによりオプションで利用される
xid 4 トランザクションID。クライアントによりランダムな数が設定される
secs 2 クライアントがアドレスの取得もしくは更新を開始してからの時間
flags 2 フラグ群
ciaddr 4 クライアントの IP アドレス
yiaddr 4
siaddr 4 ブートストラップに利用する次のサーバのIPアドレス。サーバからの DHCPOFFER, DHCPACK で返される
giaddr 4 ブーティングに利用するリレーエージェントの IP アドレス
chaddr 16 クライアントのハードウェアアドレス
sname 64 サーバーのホスト名。オプション
file 128 ブートファイル名。
options var (321~) 追加のパラメーターフィールド
最低 576 オクテット必要。
DHCP が提供するサービス
クライアントのためのネットワークパラメーターの永続的なストレージ
DHCP サービスは各クライアントのためのキーバリューストアをもっている
クライアントは DHCP サーバに対し自身の設定情報を取得するクエリを発行できる
クライアントから明示的な指定がない限り、キーは IP サブネット番号とハードウェアアドレスの組になる
ネットワークアドレスの動的割り当て
メカニズムはシンプル。クライアントは一定期間のあるアドレスの利用をリクエストする
該当アドレスを該当時間別のクライアントに割り当てないことを保証する
クライアントがアドレスを要求した場合は同様のアドレスを返そうと試みる
https://tools.ietf.org/html/rfc2131#section-2
役割
IPアドレス の自動割り当て
データセンタの大量のサーバに対して、固定IPアドレスを設定する
KickStart に代表される、サーバの自動インストール機能にも関わる
DHCP がない時代は、全て手動で PC に設定していく必要があった。
DHCP が提供するもの
IP アドレスだけを提供するだけではなく、そもそも IP アドレスが割り当てられただけではデバイスはネットワーク通信ができない。基本的には、以下の 3 点が必要となる。
IPアドレス
サブネットマスク
デフォルトゲートウェイ
DHCP は追加で、DNS サーバのIPアドレス、ドメイン名等の追加情報を提供する。
プロトコルの概要
DHCP は IP アドレスが割り振られていない状態で通信を行わなければならない。このために UDP (UserDatagram Protocol) が利用される。サーバ/クライアントは各々以下のようにポートを開けて通信しあう。
DHCP サーバ: 67番ポート
DHCP クライアント: 68番ポート
また、UDP パケットには以下の情報が含まれている。
ヘッダ
送信先/宛先MACアドレス
送信元/宛先IPアドレス
送信元/宛先ポート番号
table:dhcp
手順名 送信元 やること 送信方法
DHCP-DISCOVER クライアント IP アドレスの割り当てを要求 ブロードキャスト。送信元 IP は便宜上 0.0.0.0
DHCP-OFFER サーバ IP アドレスの候補を提案する ユニキャスト。 IPアドレスがないと受け取れないクライアント の場合はブロードキャストで送信を指定可能。
DHCP-REQUEST クライアント IP アドレスの使用をリクエスト ブロードキャスト
DHCP-ACK サーバ 許諾 ユニキャスト
手順3, 4 の役割は以下。
サブネットに複数の DHCP サーバがあった場合への対処
複数の DHCP サーバが DHCP-OFFER を送信すると、最初に受け取ったものがクライアントに採用される
この時、受け取られなかった IP アドレスを使用済みとして登録しないようにする
IPアドレスの際割り当て処理をやりやすくする
有効期限を更新したい場合は、手順3. 4 を行えば良い (1 からやり直す必要はない)
さらに、クライアントは本当に割り当てられた IP アドレスが他のパソコンで利用されていないか確認するために、ARP を利用することがある。(仕様では必須ではない)
もし他のクライアントも利用していたら、利用停止を伝えるメッセージ DHCPディクライン を送信し、もう一度設定し直す。
http://itpro.nikkeibp.co.jp/members/NNW/NETPOINT/20041116/152622/
ブロードキャスト
ブロードキャストで送信するというが、どういう仕組みなのか少し詳しく見てみる。
ブロードキャストのパケットは、宛先に *ブロードキャストアドレス* が指定されている。IPアドレスの場合だと、これは 255.255.255.255 になる。
同じサブネットのデバイスは、スイッチングHUB等の *L2スイッチ* で接続されている。L2スイッチの仕様として、宛先MACアドレスがブロードキャストアドレスのパケットは、サブネット内の全ての機器にパケットを送信する。また、パケットを受け取った機器は、宛先IPアドレスが自身のアドレスであるものだけを受け取る。しかし、IPアドレスがブロードキャストアドレスの場合は、絶対に受け取ることになる。ただし、宛先ポート番号が空いてなければ受け取れない。
IP アドレスの割り当て方
DHCP での IP アドレスの割り当て方は以下の二種類。
動的割り当て
期間を指定して割り当てる (リース)
リース期間をすぎても、なるだけ同じ IP アドレスを取得し続けるようになっている
*パソコン稼働中に、リース期間が残り半分になった時*
1. クライアント -(DHCPリクエスト)-> DHCPサーバ
ユニキャストでリクエスト
2. DHCPサーバ -(DHCPアック)-> クライアント
OK であることをユニキャストでレスポンスする
*パソコンが再起動した時*
1. クライアント -(DHCPリクエスト)->>
ブロードキャストでリクエスト
再起動するまでの間で別のネットワークに繋がっているかもしれないので
2. DHCP からのレスポンス
1. DHCPアック: 以前と同じネットワークなら許可
2. DHCPナック: 知らないIPアドレスであれば拒否
3. ナックを受診したら、 DHCPディスカバー をブロードキャストで送信する
静的割り当て
サーバマシンなどに向いている
パソコンの LAN カードの MAC アドレスと IP アドレスを紐づける
http://itpro.nikkeibp.co.jp/article/COLUMN/20071010/283862/zu03_02.jpg
http://itpro.nikkeibp.co.jp/article/COLUMN/20071010/283862/
DHCP のオプション
DHCP メッセージのオプションフィールドにオプションが入っている。色々ある。
http://itpro.nikkeibp.co.jp/article/COLUMN/20071010/284080/zu04_01.jpg
DHCP リレーエージェント
DHCPリレーエージェント
別のネットワークにある DHCP サーバに DHCP メッセージを中継する仕組み。
ブロードキャストで送られるメッセージはルーターを超えて別のネットワークには届かない
http://itpro.nikkeibp.co.jp/article/COLUMN/20071010/284080/zu04_02.jpg
http://itpro.nikkeibp.co.jp/article/COLUMN/20071010/284080/
#Network #Protocol