上一期文章介紹了DHCP協定的歷史與運作機制等等，相信各位讀者對於DHCP協定已經有一個很扎實的認知。本期接著介紹更深入的DHCP議題，也就是與DHCP協定的安全性以及可靠性相關的技術。
本文將先從DHCP協定的可靠性談起，接著講述DHCP協定的安全性，然後詳細介紹與DHCP協定安全性相關的解決方案。
DHCP協定的可靠性
DHCP協定等於是開啟了一般電腦或上網設備在IP層的通訊，因此DHCP協定的可靠性是一個頗為重要的議題。一般來說，DHCP協定透過以下的過程來提升可靠性：
- 1. 定期更新IP租約（Periodic renewal）
- 2. 重新連結DHCP伺服器（Rebinding）
- 3. 容錯轉移（Failover）
接下來，就來看看如何進行這些步驟來提升DHCP協定的可靠性。
定期更新IP租約
如同大部分讀者所知道的，事實上，DHCP用戶端（例如一般個人電腦或手機等等）從DHCP伺服器端所取得的IP位址是有租約（Lease）的。也就是說，這個IP位址只能被DHCP用戶端使用一段時間而已。時間一到，就必須重新更新，取得新的租約。而定期更新所指的，就是定期去更新這個租約。
 |
| ▲對上網設備的IP層通訊而言，DHCP的可靠性可說事關重大。Photo: John Blyberg (CC BY 2.0) |
但是，何時必須開始重新申請租約呢？如果時間到才去申請，是否有可能造成中間某段時間沒有網路可以用？沒錯，為了避免這樣的問題（也就是提升可靠性），每當DHCP用戶端在「租約一半的時間」到的時候，就會開始發送DHCP request封包給DHCP伺服器。這個時候，DHCP用戶端所發送的是Unicast，並非廣播封包。而且只會送往原本發送租約給DHCP用戶端的那一台DHCP伺服器。
當然，在這樣的情況下還是有風險。有可能DHCP伺服器端剛好關閉、重新開機，或是任何無法處理這個DHCP request的時候，若碰到這樣的情況，DHCP用戶端會一直持續發送DHCP request，直到DHCP伺服器可以處理為止。
重新連結DHCP伺服器
如果DHCP伺服器真的在過了很長一段時間還是無法處理DHCP requests，那DHCP用戶端就會採取其他做法：Rebind。簡單來說，就是重新找尋可以提供服務的DHCP伺服器。
剛才第一個步驟當中，DHCP用戶端所發送的DHCP request是採用Unicast的方式，也就是說，只有原本提供IP租約的DHCP伺服器才會收到DHCP request。
而這邊的步驟則是會發送廣播封包方式的DHCP request。差別在於希望所有的DHCP伺服器都能收到這樣的DHCP requests。因為原本的DHCP伺服器無法提供服務，所以透過廣播封包的方式來試試看有哪一個其他的DHCP伺服器能夠提供服務，並且提供IP租約。
但為了確保重新連結的過程是沒有問題的，當DHCP用戶端成功連上新的DHCP伺服器之後，新的DHCP伺服器必須擁有正確的用戶端資訊。在兩個DHCP伺服器之間確保正確無誤的資訊能夠完整被維護，是一件很複雜很困難的事情。
因此，IETF針對這樣的問題開發了可容錯的DHCP伺服器方式，不過這不是這一篇文章所要著重的重點，也許以後有機會再跟各位分享介紹。
容錯轉移
如果連重新連結DHCP伺服器這樣的步驟都失敗了，當然結果就是沒有IP可以使用，因為IP租約已經過期了。此時，DHCP用戶端就會回到最開始的情況，重新透過廣播封包發送DHCP Discovery。
也因為沒有任何的IP位址，所以只要有IP位址發送下來，這個DHCP用戶端就會接受並且使用，也因此，新得到的IP位址有極大的可能性會與原本的IP位址不一樣，導致的結果就是原本的某些網路連線可能就會斷掉並且重新連線。
DHCP協定的安全性
介紹過DHCP協定的基本運作過程之後，想必大家會發現，其實在DHCP伺服器和DHCP用戶端之間的交互運作過程中，完全沒有任何用戶認證（Authentication）的程序，也因此可以說毫無安全性可言，所以DHCP協定有不少安全上的漏洞。