通訊網路/DHCP協議

動態主機配置協議

動態主機配置協議 (DHCP) 允許手動和自動分配 IP 地址（參見 IETF rfc 2131 & 2132）。當新機器加入網路或現有機器嘗試續租其 IP 地址時，就會使用 DHCP。DHCP 是一個較舊的協議（稱為“引導協議”[BOOTP]）的擴充套件，並且與 BOOTP 向後相容。IP 地址分配有三種方法

   Manual:     An administrator manually assigns the IP address; tedious but most secure method.

   Automatic:  DHCP server assigns permanent IP address to requesting client.

   Dynamic:    DHCP server "leases" IP address to requesting client. The IP address is only valid for a limited period of time;
               after which the client must request a renewal or ask for a new IP address.

到目前為止，最常見（也是最詳細）的方法是動態方法，我們將把注意力集中在動態方法上。以下圖表顯示了新客戶端請求 IP 地址的典型順序。請注意，此描述顯示 DHCP 伺服器位於與新客戶端不同的網路段上。但這並不是必需的。

示例

圖 1

在圖 1 中，一個新加入網路的客戶端需要一個 IP 地址。由於它不知道 DHCP 伺服器的位置，因此客戶端在本地網路上廣播 (步驟 1) 一個 DHCPDISCOVER 訊息。訊息包包含硬體識別符號（通常是 MAC 地址）、源埠 (68)、目標 IP (255.255.255.255)、目標埠 (67) 和一個隨機生成的交易 ID。可選地，客戶端可以在訊息中指定它想要的 IP 地址和租賃期限。DHCP 中繼器接收到廣播訊息後，它會使用閘道器 IP 地址 10.1.2.9 填充資料包的 "giaddr" 欄位。此資訊至關重要，因為 DHCP 伺服器需要它來確定客戶端位於哪個子網，從而確定要分配給客戶端的 IP 地址。之後，DHCPDISCOVER 訊息透過單播 (步驟 2) 中繼到 DHCP 伺服器。單播而不是廣播就足夠了，因為 DHCP 中繼器知道 DHCP 伺服器的確切位置。出於同樣的原因，DHCP 中繼器不允許另一個網路段 10.1.1.X 接收訊息。

DHCP 伺服器接收到 DHCPDISCOVER 請求後，會分配一個 IP 地址，將其標記為已使用，然後將 DHCPOFFER 訊息廣播回請求的客戶端。此訊息包包含 DHCP 伺服器的 IP 地址、客戶端的硬體識別符號、相同的交易 ID 以及分配給客戶端的 IP 地址。可選地，訊息還可以包含租賃時間、子網掩碼、預設 TTL、預設路由器以及許多其他引數。

圖 2

在圖 2 中，DHCP 伺服器為客戶端分配新的 IP 地址 10.1.2.3，並將 DHCPOFFER 訊息廣播到其網路 (步驟 3)。當 DHCP 中繼器看到 DHCPOFFER 廣播時，它會將廣播中繼到 10.1.2.X 網路，並且僅限於該網路 (步驟 4)。新客戶端看到 DHCPOFFER 訊息後，會接受該 IP 地址 (步驟 5) 並準備使用 DHCPREQUEST 資料包向 DHCP 伺服器傳送確認訊息。請注意，客戶端不必接受此 IP 地址，在這種情況下，它不會發送 DHCPREQUEST 訊息。如果多個 DHCP 伺服器傳送 DHCPOFFER，則客戶端可以選擇接受哪個伺服器。如果由於某種原因，DHCPOFFER 訊息始終無法到達，則客戶端會重新廣播 DHCPDISCOVER 訊息。

圖 3

如果客戶端在初始 DHCPDISCOVER 訊息中包含了可選資訊，則它必須在後續的 DHCPREQUEST 訊息中包含相同的資訊。在圖 3 的步驟 6 中，新客戶端透過向 DHCP 伺服器廣播 DHCPREQUEST 來確認它想要使用 IP 地址 10.1.2.3。DHCP 伺服器接收到此訊息後（再次藉助 DHCP 中繼器），它首先確保它是預期的目標，因為客戶端可能正在響應另一個 DHCP 伺服器。如果此 DHCP 伺服器不是預期目標，那麼它知道其他 DHCP 伺服器正在處理此客戶端。因此，此 DHCP 伺服器可以丟棄之前分配給該客戶端的任何 IP 地址。如果此 DHCP 伺服器是預期的接收者，則它必須驗證它在之前傳送給此客戶端的 DHCPOFFER 訊息中指定的所有可選引數是否仍然有效。假設到目前為止一切都正常，則 DHCP 伺服器會發送 DHCPACK 廣播 (步驟 8) 來告訴客戶端現在可以正式使用其新的 IP 地址。但是，如果出現問題，則會廣播 DHCPNACK。無論哪種方式，DHCPACK 或 DHCPNACK 將是 DHCP 伺服器在動態 IP 地址分配序列中傳送的最後一條訊息。

假設客戶端收到了路由器中繼的 DHCPACK (步驟 9)，則建議客戶端驗證沒有其他主機使用相同的 IP 地址。這通常透過簡單的 ARP 探測來完成。對探測的任何響應都意味著另一個客戶端已經在使用該 IP 地址。在這種情況下，客戶端必須向 DHCP 伺服器傳送 DHCPDECLINE 訊息。之後，客戶端將需要從 DHCPDISCOVER 階段重新開始整個過程。在大多數情況下，客戶端的 ARP 探測沒有響應。這意味著客戶端可以繼續使用分配的 IP 地址以及訊息包中儲存的任何其他可選資訊。

如果客戶端收到的是 DHCPNAK 而不是 DHCPACK，那麼它別無選擇，只能從頭開始，即從 DHCPDISCOVER 階段開始。最後，如果客戶端在一定時間段後沒有收到任何 DHCPACK 或 DHCPNAK 訊息，那麼它會重新廣播 DHCPREQUEST 訊息。

其他 DHCP 訊息

  IP Renewal:  If the client wishes to renew its existing IP address (usually because of expiring lease), it unicasts a special  
               DHCPREQUEST message that indicates it's renewing (and not asking for new) IP address. The DHCP server can choose 
               to extend the lease or reject it. Either way, it must inform the client via a DHCPACK message.

  Release IP:  The client can request its current IP address be relinquished by issuing a DHCPRELEASE message (via unicast) to          
               the DHCP server. The message packet must contain the IP address and the hardware identifier of the client. Upon 
               receipt, the DHCP server marks the client's IP address as unallocated.

  Inform:      The client already has an IP address but needs additional configuration parameters, such as default TTL, subnet 
               mask, etc. So it sends a DHCPINFORM message to the DHCP server. In response, the DHCP server unicasts a DHCPACK

安全問題

DHCP 本質上是不安全的，因為它沒有內建的認證機制。以下是一些安全弱點的示例。

  Problem:  The DHCP server does not know if requests are from a legitimate new client or a rogue host pretending to be one.
  Impact:   This could lead to IP addresses allocated to spoofed MAC addresses that don't exist, and eventually exhaust the pool  
            of legitimate IP addresses. Thus new hosts cannot added to the network.
  Solution: Manually assign IP addresses or manually verify every new client requesting IP address. Can also audit the DHCP 
            database. But these are all fairly time-consuming. No simple way to address this issue.

  Problem:  A new client doesn't know if responses are coming from real DHCP server or rogue host pretending to be a DHCP server.
  Impact:   If the client accepts all the information given to it by the rogue DHCP server, then false information (e.g. bad 
            subnet mask) could render the client useless.
  Solution: Can identify fake DHCP servers by using security tools that send out DHCPDISCOVER & DHCPREQUEST messages and flag any
            suspicious information returned.

總結

動態主機配置協議 (DHCP) 是一種方便但並不安全的為新新增到網路的主機分配 IP 地址的技術。它還可以用於延長現有 IP 地址的租賃期限、刪除主機的 IP 地址或向請求的主機提供初始配置引數。

練習

問題

使用 DHCP 部分中說明的示例，解釋如果 DHCP 伺服器位於與新客戶端相同的網路段上，新客戶端與 DHCP 伺服器之間的互動將如何改變。
(T/F) 新客戶端在收到 DHCPOFFER 後的 IP 地址後，應該驗證沒有其他主機正在使用該 IP 地址。

答案

唯一的區別是 DHCP 中繼器不會參與。因此，DHCP 伺服器接收的是廣播而不是單播，訊息包的 "igaddr" 欄位將為空。
錯誤 - 客戶端必須等待 DHCPACK（而不是 DHCPOFFER），因為在收到 DHCPACK 之前，IP 地址尚未正式分配給新客戶端。

參考文獻

http://tools.ietf.org/html/rfc2131

http://www.windowsecurity.com/articles/DHCP-Security-Part1.html

http://www.eventhelix.com/RealtimeMantra/Networking/DHCP.pdf