0 概要 ・複数サーバでサーバの信頼性を上げる ・そのためには、複数のサーバが同じ情報(parameter, binding)を持っている 必要がある ・ダイナミックな割り当てやリースの延長などによって生じる、サーバ間のデー タベースの違いを同期させるためのプロトコル 1 はじめに ・全てのDHCPサーバは、parameter, bindingに関して同じ情報を設定されなけ ればならない ・DHCPサーバは、新しく動的にアドレスを割り当てたり、リースを延長するの で、サーバ間のbindingが一致しない状況が起こる ・サーバ間プロトコルは、DHCPサーバ間でbinding情報を自動的に同期させる ・2章でサーバ間プロトコルの提供する機能について述べる。 ・3章ではDHCPサーバが、どのようにbindingのassignment, release, expire などを協調して行い、DHCPサーバとクライアント間の矛盾なきinteraction を実現するかを述べる。 ・4章では、今後に議論すべき問題点を示す 2 プロトコル仕様 ・DHCPのサーバ間プロトコルの持つ機能は以下の4つ: 1. アドレス割り当ての情報を配布 2. DhcpReleaseによるアドレス返却の情報を配布 3. 割り当て可能なアドレスの再配分 4. 特定のアドレスが「使用中」であるかを問い合わせる ・各サーバは; * 各々の間でTCPコネクションを張る → これを通じて上記の4機能について通信する * 他のサーバのリストを保持している * アドレスプールを持っている * 定期的に、あるいは必要に応じて1つ〜全てのサーバと通信する * すべてのDHCPサーバの時計は同期が取れている(NTPなどを使用) ・DHCPサーバ群によって管理されるbindingの集合は、本質的には分散データ ベースであり、サーバ間プロトコルで一貫性を保つ ・クライアントは、同期が取られる前の古いデータに基づいて、間違った情報 を受け取る可能性がある 3 プロトコルの動作 DHCPサーバ群で管理されるアドレス割り当て情報が変更されるのは次の4つ 1. 新しいアドレス割り当て 2. リースの延長 3. リースの期限切れ 4. アドレスの解放 3.1 新しいアドレス割り当て ・INIT状態のクライアントにアドレスを割り当てたら、bindingを追加し、他 のサーバに新しいbindingを伝える ・アドレスを割り当てるサーバは、アドレスプールから割り当て可能と思われ るアドレスを選び出し、他のサーバにそのアドレスの状態を問い合わせる ・もし他のサーバの内の一つでも「使用中」だと答えた場合には、別のアドレ スを選び出して同様の処理を繰り返す ・「使用中」だという応答が返ってこなければ、そのアドレスをクライアント に割り当てる <議論> 1. 新しいbindingは直ちに他のサーバへ転送するのではなく、定期的に更新す るようにして効率化することも可能 ・この遅延を持つbindingの伝播方式の主要な欠点は、新しいbindingが 他のサーバに通知されるまでの間、冗長性がなくなることである ・遅延伝播を用いたとしても、割り当て候補のアドレスについて他のサー バへ問い合わせることによって、複数のサーバが別々のクライアント に同じアドレスを割り当てることは回避される 2. 効率化のため、DHCPサーバは他のサーバによってチェックされた「割り当 て可能アドレス」のリストを管理する ・このようなリストを管理しているサーバは、あるアドレスの割り当て 状態に関する問い合わせが届いた場合、次のどちらかを実行する a.「使用中」であると応答する b. チェック済みアドレスのリストから、そのアドレスを削除して 「未使用」と応答する 3. DHCPサーバは、他のサーバに対して割り当て可能なアドレスを問い合わせ ることも有り得る。そのような場合、(もしあれば)リモートサーバ上の割 り当て可能アドレスのリストとして示されるだろう 4. サーバはアドレスを再割り当てするまえに、他のサーバと無事に通信し終 わらなければならない(MUST) 3.2 リースの更新 ・DHCPサーバは、INIT-REBOOT状態のクライアントから送られたDhcpRequestメッ セージに対し、リースの延長をすることができる ・リースを延長したサーバは、他のサーバへそれを伝播する。この伝播の詳細 を設計する場合には、少々注意を払う必要がある * サーバはクライアントが現在保持している有効期限について合意をとら なければならない * リースを延長したサーバは他のサーバをチェックし、一番最近のリース を決定しなければならない * 決定したら、他の全てのサーバへ通知する <議論> ・リースを延長してから、それを他のサーバに通知するまでの間、ある特定の bindingに関して、サーバ間で有効期限が異なる状態が生じる。 ・この間に(古い情報に基づいて)、クライアントがリブートして古い有効期限 を入手したり、あるいはサーバが「リースは期限切れである」とみなすかも 知れない。 ・もしクライアントが(延長されていない)古い有効期限を受け取った場合、ク ライアントは古い値に有効期限をセットし直すだろう。リースが十分に有効 期限に近ければ、クライアントは期限の延長を試みる。この延長処理が他の サーバで処理されたとしても、サーバ同士で合意して、最後にクライアント に送信された有効期限に収束する。 ・サーバはリースの延長を通知する前に、リースが期限切れであると判断する かも知れない。もしサーバが、単にそのbindingをデータベースから削除す るにとどめ、他の明示的な動作は何もしない。そうすれば、延長されたリー スが(その延長した)サーバから伝播される。 ・リースの期限切れの詳細については次節で述べる。 3.3 リースの期限切れ ・DHCPサーバが、あるbindingが期限切れと判断した場合、サーバはその bindingをデータベースから取り除くだけで、なにも明示的な動作を行わない。 ・そのbindingのアドレスは、必要ならば後で復旧されるだろう。また再利用 の前に3.1で述べたルールに基づいてチェックされる。 <議論> ・サーバがデータベースからの削除以外に明示的な動作を行わないので、「時 期尚早な期限切れ」(古い有効期限データに基づく期限切れ)も、なんら影響 がない。 ・延長を行ったサーバは、それに関して他のサーバに知らせ、新しい有効期限 を反映させる。 ・「時期尚早な期限切れ」によって引き起こされうる問題点は、実際にはまだ そのアドレスが使用中にもかかわらず、再利用されてしまうことである。 ・アドレス再利用の前にチェックを行うという規則により、他のサーバが再利 用しようとするアドレスのbindingを持っていないこと、およびアドレスが 使用中でないことを確かめる。 3.4 リースの解放(Release) ・DHCPサーバがクライアントからDhcpReleaseを受け取ったら、他の全サーバ に通知する。他のサーバはデータベース内の該当するleaseを廃棄する。ア ドレスは、必要ならば、3.1節のルールに従って、後で回復される。 ・DhcpReleaseを処理中のサーバが、そのDHCPクライアントが該当するアドレ スに対するDhcpRequestを送出し、他のサーバがそれに応答するのに気づい た場合、クライアントはアドレスを使い続けていて、リースも依然有効だと みなす。この場合、DhcpRequestに応答したサーバがbinding情報を保持し、 他のサーバに通知する。 <議論> ・第2パラグラフでの議論は、実際にはクライアントによるDHCPプロトコルの 違反である; DhcpReleaseを送信したクライアントは、INIT状態へ遷移して 新しいアドレスを要求しなければならない。 ・しかし、このようなエラーをサーバがクライアントへ通知するメカニズムは DHCPには存在しないため、サーバはエラーに対しても便宜を図ってbinding データベースの一貫性を保持しなければならない。 4 Open Questions ・binding情報が無効になる状況は、これで全てか? ・このような解決方法で正しいか? ・INIT状態の場合、EXISTING/NEW bindingオプションが必要となる なぜならDHCPサーバ間の怠惰な同期により、あるサーバは既存のbindingを 保持しているが、一方では保持していないことが起こり得る。最適化のため にクライアントは、複数のサーバからのDhcpOfferに含まれる「既存binding」 と「新binding」を選別できなければならない。新しいオプションを定義す れば、DhcpOfferメッセージが既存/新bindingのどちらを表すものであるか をクライアントに示すことができる。 ・個々のサーバは、他のサーバを全て知っていなければならない 個々のサーバが互いに全てのサーバの存在を知っていなければならないとす ると、DHCPサーバの設定に更に手間が必要となる。しかしながら、この手間 の増加は、おそらく設定の他の部分とは非常に関係が少ない。 ・個々のサーバはアドレスを再割当する前に、他の全てのサーバと通信しなけ ればならない ここで、DHCPサーバのどれか一つでも通信が出来なくなると、新しいDHCPク ライアントはアドレスを割り当ててもらえなくなるという潜在的な問題があ る。サーバは予めチェック済のアドレスリストを管理し、その中のアドレス はアドレス割当の時点で他のサーバと通信しなくても、割り当てることがで きる。こうすることで、問題を改善することができる。 あるDHCPサーバが他の全てのサーバと通信できなくなった場合の残りのサー バの特別動作について、本プロトコルに追加定義が必要かも知れない。 ・割り当て可能なアドレスの「公平な」配分を達成するための、サーバ間の協調 サーバ同士が互いに協力して、各々が個々のネットワークに対して、均等な 量のチェック済アドレスプールを確実に持つことができるように、プロトコ ルに機構ないし定義の追加が必要かも知れない。 ・データベースの矛盾に対するユーザの介入 問題が「本当の」悪夢に成りかねない場合に、複数のDHCPサーバに存在する 集合データベースを修正する。 ・アドレスチェック時の潜在的デッドロック 二つのサーバが同じアドレスを再割り当てしようとして、同時にチェックし た時のことを考えよ。 ・新しいサーバに対する潜在的な設定 サーバ間プロトコルの付加的な使い道として、新しいDHCPサーバを設定でき るようにすることが考えられる。サーバの設定ファイルを読み込み、DHCPサー バのリストへ新しいサーバを追加することを可能にするための拡張を、サー バ間プロトコルに施すことを考えよ。 新しいサーバは単に既存のサーバ郡のアドレスを与えられるだけで設定でき るかも知れない。新しいサーバは、他の既知のサーバのリスト、(割り当て) 候補アドレスのプール、あらゆる特別な設定情報(例えばベンダークラス情 報)、それに既存bindingなどを読み込むことが出来るだろう。新しいサーバ は、自身を他の全サーバへアナウンスすることができる。 ・DHCPサーバのメンテナンス おそらく全てのサーバからデータベース情報を読み込んで、そこに(例えば、 複数クライアントへのアドレス割当とか、bindingが全てのサーバに複製さ れていないとか、リースの有効期限が一貫性を持っていないなどの)衝突や 矛盾が生じていないかチェックするサーバ管理ツールを作るチャンスがある だろう。