ISC-DHCPサーバはリース延長要求にブロードキャストで応答するので端末に届かない！？

自分のためのDHCPに関する備忘録みたいな感じで。

ISC-DHCPサーバからProDHCPに移行する際に、ISC-DHCPサーバを完全に止めて入れ替えるのであれば簡単なのですが、セグメントごとに移動していきたい場合などは、両方のサーバを稼働させ、移動したいセグメントで払い出しをできない設定に変更して、端末に再取得させる方法は誰もが思いつく方法だと思います。

ところが、ISC-DHCPサーバはこの方法で移行する場合に落とし穴があります。

RFC2131の記述も曖昧なのが悪いのですが、ISC-DHCPサーバはリース延長のDHCPREQUEST、つまり、ユニキャストで飛んでくるDHCPREQUESTにNAK応答する際に、ブロードキャストで応答します。DHCPサーバと端末が同一セグメントの場合はブロードキャストでも届きますが、別セグメントの場合には当然届きません。RFCではリース延長のDHCPREQUESTにNAK応答する想定がそもそもないような記述になっている感じです。

まあ、NAKが端末に届かなくても、そのうちリース時間が切れれば端末はDHCPDISCOVERからやり直して、移行先のサーバと上手いことやってくれると思うのですが・・・DHCPクライアントの実装は意外といい加減な端末が多く、数社の有名ネットワーク機器メーカーのルーターなどで、DHCPDISCOVERから移行先のサーバから払い出しを受けてくれるものの、なぜかリース延長のユニキャストのDHCPREQUESTだけは永遠に元のサーバに投げ続ける端末がいたりします。それでもちゃんと移行先のDHCPサーバから払い出しを受けたものを使っているので、ネットワーク的には問題にはならないのですが、元のDHCPサーバの方にいつまでもNAKのログが出続けてしまいます。

こんな場合は、NAK応答で端末が切り替わってくれることは期待せず、あらかじめリース時間を短くして、移行させる前にリース切れを一度発生させ、それから移行先にリレーエージェントの向け先を変更すると上手く行く感じです。それができない状態でリレーエージェントの向き先を変更してしまった場合は、端末の電源を入れ直すか、移行先のDHCPサーバで一度NAK応答するような設定にしてNAK応答を端末に届かせるとまともな状態に戻ってくれる感じです。

しかし・・・ISC-DHCPサーバも、他のセグメントからユニキャストで届いたDHCPREQUESTにブロードキャストで返しても意味がないことくらい誰でもわかるわけですから、RFCの記述の通りに作るのではなく、少し考えて作ればこんなことにはななかったと思うのですが・・・。

ProDHCPはユニキャストで届いたDHCPREQUESTにはユニキャストでNAK応答します。私が作ったときにRFCをまじめに読まずに、こうするのが当然だろうと作ったためなので、RFCの仕様の漏れに気がついていたわけではないので、偉そうなことは言えませんが。。