Oracle® Solaris 11.2 での DHCP の作業

印刷ビューの終了

更新: 2014 年 7 月
 
 

DHCP クライアントプロトコルはネットワーク構成情報をどのように管理するか

DHCPv4 クライアントプロトコルと DHCPv6 クライアントプロトコルでは、ネットワーク構成情報の管理方法が異なります。主な相違点は、DHCPv4 では単一のアドレスのリースとそれに関連するいくつかのオプションのためにネゴシエーションが行われることです。DHCPv6 では一連のアドレスとオプションに対して一括でネゴシエーションが行われることです。

DHCPv4 クライアントとサーバー間の対話の概要については、Chapter 1, DHCP について (概要)を参照してください。

DHCPv4 クライアントはネットワーク構成情報をどのように管理するか

DHCP サーバーから情報パケットを取得すると、dhcpagent はネットワークインタフェースを構成し、使用可能にします。デーモンは、そのインタフェースを IP アドレスのリース期間が終わるまで制御し、その構成データを内部テーブルに保持します。システム起動スクリプトは dhcpinfo コマンドを使用して内部テーブルから構成オプションの値を抽出します。それらの値は、システムを構成し、システムがネットワーク上で通信できるようにするために使用されます。

dhcpagent デーモンは、一定時間 (通常はリース期間の半分) が過ぎるまで何もせずに待機します。この時間が過ぎると、デーモンは、リースの延長を DHCP サーバーに要求します。dhcpagent デーモンは、インタフェースの停止や IP アドレスの変更がシステムから通知された場合、ipadm コマンドから指示があるまでそのインタフェースを制御しません。また、dhcpagent は、インタフェースが適切に動作し、IP アドレスが変更されていないことを検出すると、リースの更新要求をサーバーに送信します。リースを更新できない場合、dhcpagent はリース期間の満了時にそのインタフェースを停止します。

dhcpagent がリースに関連するアクションを行うたびに、このデーモンは /etc/dhcp/eventhook という実行可能ファイルを探します。この名前の実行可能ファイルが見つかると、dhcpagent はこのファイルを起動します。イベント実行可能ファイルの使用については、DHCP クライアントのイベントスクリプトを参照してください。

DHCPv6 クライアントはネットワーク構成情報をどのように管理するか

クライアントとサーバーの間の DHCPv6 通信は、クライアントがサーバーを見つけるために要請メッセージを送信することによって開始されます。応答として、DHCP サービスに使用可能なすべてのサーバーが通知メッセージを送信します。サーバーのメッセージには、複数の IA_NA (非一時アドレス用アイデンティティーアソシエーション) レコードに加え、サーバーが提供できるほかのオプション (DNS サーバーアドレスなど) が含まれています。

クライアントは、独自の IA_NA/IAADDR レコードを要求メッセージに設定することにより、特定のアドレス (またはその複数) を要求できます。通常、クライアントが特定のアドレスを要求するのは、古いアドレスが記録されており、可能な限り同じアドレスがサーバーから提供されることを望む場合です。クライアントの動作にかかわらず (クライアントがまったくアドレスを要求しない場合でも)、サーバーは 1 つの DHCPv6 トランザクション用に任意の数のアドレスをクライアントに提供することができます。

クライアントとサーバーの間で行われるメッセージのやり取りは次のとおりです。

  • クライアントがサーバーを見つけるために要請メッセージを送信します。

  • サーバーは通知メッセージを送信して、DHCP サービスに使用可能であることを示します。

  • クライアントは要求メッセージを送信して、もっとも大きい優先値を持つサーバーに、IP アドレスなどの構成パラメータを要求します。サーバーの優先値は、最低値 0 から最高値 255 の範囲で、管理者によって設定されます。

  • サーバーは、アドレスリースと構成データを含む応答メッセージを送信します。

通知メッセージ内の優先値が 255 であれば、DHCPv6 クライアントはただちにそのサーバーを選択します。もっとも優先値の高いサーバーが応答しない場合や要求メッセージに正常な応答を返すことができない場合、クライアントは、取得済みの通知メッセージの中で優先値の高いものから順にサーバーを検索します。すべての通知メッセージの検索が終わると、クライアントは再び要請メッセージを送信して処理を繰り返します。

選択されたサーバーは、要請メッセージまたは要求メッセージへの応答として、割り当てるアドレスと構成パラメータを含む応答メッセージを送信します。