DHCP Client按Option60分流的研究與實現

文榮，李凱達，王志謙

(北京郵電大學網絡技術研究院，北京，100876)

DHCP Client按Option60分流的研究與實現

文榮，李凱達，王志謙

(北京郵電大學網絡技術研究院，北京，100876)

動態主機配置協議(DHCP)主要用來動態提供配置參數給因特網上的主機，一方面從DHCP服務器傳送主機特定的協議配置參數到主機，另一方面自動分配網絡地址給主機。目前本地局域網大多使用高速公共因特網接入技術和高速調制器, 并使用動態主機配置協議分配用戶的主機地址。然而, 隨著數字電視等業務的發展，用戶家庭需要分配IP地址的設備越來越多，如何將用戶不同設備的DHCP請求分流至特定的服務器就成為日益迫切需要解決的問題。本文針對目前在局域網普遍使用的DHCP及其為解決分流問題而引進的Option60機制進行簡單的描述, 并具體闡述其實現方式。

動態主機配置協議；可選域60；中繼代理；分流

Abstract:The Dynamic Host Configuration Protocol (DHCP) is mainly used to provide configuration parameters for hosts on the Internet. On the one hand, it transmit host-specific configuration parameters from the DHCP server to the client host, and on the other hand, it assign network addresses for the client host. Currently, most of the local area networks access Internet via high-speed public Internet access technologies and high-speed modulator. And use DHCP to distribute host address for the user's devices. However, with the development of digital television services, more and more devices need ip addresses to be assigned. How to user requests for different devices diverted to a particular DHCP server has become increasingly it’s a urgent problem to be solved that how to divert DHCP request from different user devices to specific server. This paper describes both the Option60 mechanism aiming at the DHCP commonly used in LAN and its diverting problems, and the implementation in detail.

Key words:Dynamic Host Configuration Protocol, Optional Field 60, Relay Agent, Diversion

1.問題的提出

在現今的網絡中，IP地址的分配方式大多采取的是DHCP的方式。隨著廣電運營商為用戶提供服務的增多(如接入Internet、IPTV、數字電視等)，用戶端的設備(如cablemodem、機頂盒等)也隨之增多，對為這些設備提供IP地址的DHCP服務器而言，其壓力越來越大，而且同時也不方便網絡管理人員的管理。

因此，運營商們希望能實現如下場景：一個DHCP客戶端從由某一廠商提供的一臺特定的DHCP服務器上取得訪問公網的IP地址，而觀看數字電視又從另一廠商提供的DHCP服務器上獲取設備的IP地址。也就是說，用特定的DHCP服務器為用戶的設備(cablemodem、機頂盒等)分配IP地址這一需求日益突顯出來。

本文針對上述問題進行研究并提出了一種實現方式。

2.DHCP過程概述

DHCP是通過DHCP服務器向提出申請的網絡主機分配IP地址等網絡配置參數。

如果要分配一個新的網絡地址，DHCP服務器與客戶間的協議交互如下：

客戶在本地子網廣播DHCPDISCOVER消息，若DHCP服務器與客戶端不在一個子網，則由DHCP中繼代理(relay agent)傳遞消息到服務器。

服務器端在收到DHCPDISCOVER后，以帶有客戶請求的網絡地址yiaddr的DHCPOFFER響應，假如服務器發現DHCPDISCOVER來自relay agent，則將DHCPOFFER直接單播送至relay agent，由其單播送至客戶，反之，則在本地子網廣播。

客戶從一個或多個服務器接收到一個或多個DHCPOFFER后選擇其中一個獲得配置參數，并將帶有標識選中服務器的DHCPREQUEST在本地子網廣播經由relay agent轉發。若客戶在規定時間內未收到DHCPOFFER，則重發DHCPDISCOVER。所有服務器將接收到DHCPREQUEST消息，根據DHCPREQUEST內的服務器標識，被選用的服務器根據客戶的硬件地址chaddr和yiaddr唯一確認客戶后，發送DHCPACK至客戶端。若服務器不能滿足客戶在DHCPREQUEST內的配置請求，則響應DHCPNAK。若服務器在一定時間未從客戶接收到DHCPREQUEST，則直接回復DHCPACK。

客戶從服務器接收DHCPACK后，首先核對消息內的配置參數(如ARP，租用時間等) ，若不一致，則發DHCPDECLINE至服務器，如果一致則進行配置，之后客戶與服務器間可以直接交互。當客戶從服務器處接收DHCPNAK，則重新啟動配置過程。一旦客戶在規定時間內未收到服務器的響應，重傳DCHPREQUEST消息，若10次重傳后，仍未收到服務器的響應，則通知用戶并回到配置初始化階段重新開始。

當客戶想釋放由服務器提供的網絡地址，可發送標識客戶硬件地址chaddr 和網絡地址ciaddr DHCPRELEASE。

DHCP 消息從客戶經relay agent(可選) 至服務器，通常為廣播包，但若客戶已知服務器的網絡地址，可直接發送單播包給服務器。relay agent將處理所有的廣播包，首先檢查消息內的網關地址giaddr，若不為零，說明在此relay agent之前，已有一代理對消息進行處理，giaddr不會被修改;若為零，relay agent將自己的網絡地址填入消息內的giaddr 作為網關地址，同時將廣播包轉為單播包送至目的地DHCP 服務器。倘若消息本來就為單播包，則relay agent 不做任何處理。

一旦DHCP 服務器構造一個合適的DHCP響應包后，先檢查giaddr域，假如此域的值不為零，服務器將響應包送至giaddr標識的relay agent的端口67。若giaddr 為零，而表示客戶的網絡地址ciaddr非零，說明客戶已經有一個當前的網絡地址，故可直接將響應包送至網絡地址ciaddr。如若giaddr、ciaddr均為零并且廣播標志位被設置為1，則服務器廣播DHCP響應包DHCPOFFERPDHCPACK，若廣播標志位未被設置，則服務器發送DHCPOFFERPDHCPACK至硬件地址為chaddr網絡地址為yiaddr 的客戶。對于DHCPNAK包，只要giaddr為零，服務器將其廣播。

DHCP relay agent只接收單播的DHCP 響應包，其首先檢查giaddr、yiaddr、chaddr、htype和hlen域，根據這些域值，relay agent能將DHCP消息送至客戶。注意，relay agent不能修改消息包內的任何DHCP 域值，應該保持消息的完整性。

通常DHCP服務器和DHCP relay agent可利用硬件地址chaddr網絡地址yiaddr將DHCP響應包送回至客戶，但是有些客戶在yiaddr未被正式配置時，不承認yiaddr 標識的網絡地址，此時客戶應該設置廣播標志位為1 ，這樣服務器和agent會廣播此響應包而非發送DHCPOFFERPDHCPACK 至硬件地址為chaddr網絡地址為yiaddr的客戶，造成死鎖。

3.Option60字段

目前本地局域網大多使用高速公共因特網接入技術和高速調制器，并使用動態主機配置協議分配用戶的主機地址。然而，大量DHCP客戶端設備的使用，也會引入標識如何標識客戶端設備的問題。這個問題可以通過引進DHCP vendor class identifier 的信息域也就是所謂的Option60來解決。

通常，Option60是由客戶端設備在形成DHCP報文時寫入的，用以標識設備的屬性。Option60包含n字節的信息，這些信息是由DHCP服務器解析的。設備供應商可以選擇定義特定的一類標識符來傳達特定的配置或其他有關識別客戶身份信息。例如，標識符可能包含客戶端設備的硬件配置信息。如果服務器不具備解析Option60字段的功能，那么服務器必須將其忽略。

4.解決方案及應用

4.1 解決方案

為解決本文所提出的問題，我們如圖1設計系統邏輯結構：

標準一級relay的功能十分簡單，負責將CPE發出的DHCP報文轉發至二級relay，再將二級relay轉發的DHCP服務器的報文發給CPE。

在標準的一級relay與DHCP服務器之間加上我們設計并實現的二級relay。二級relay用于檢查DHCP報文中的Option60字段，根據Option60字段值的不同將報文轉發至不同的DHCP服務器。簡化的二級relay功能如下：

維護配置文件：二級relay會維護一個由我們定義規則，由用戶來寫入數據的配置文件。二級relay會根據配置文件的內容來轉發一級relay的DHCP報文。配置文件的格式如下：

設備屬性標識符@DHCP Server ip:DHCP Server ip:

‘@’符號之前的為設備屬性標識符，用于標識某一類的設備。標識符支持正則表達式，所以設備標識符可以是一個具體的值串，也可是帶有通配符的正則表達式。

圖1 系統邏輯結構

‘@’標識符之后的是DHCP Server的IP地址，為某一類設備分配IP地址的服務器可能是一臺也可能是多臺。因此，‘@’之后可能是一個IP地址也可能是多個IP地址。

在配置文件的最后會加上一行默認屬性的標識符，格式如下：

對于可能不帶標識符或之前匹配都未成功的設備，就采用這行規則提供的DHCP服務器的IP地址對一級relay的報文進行轉發。

上行中繼：所有從標準一級relay轉發來的廣播或者單播DHCP消息都被此agent截取。然后對報文消息進行分析，取出報文的Option60字段的值，并參照配置文件的規則進行匹配。如果匹配成功，取出規則中DHCP 服務器的IP地址，再將報文轉發至這些DHCP服務器。若不成功，則采用配置文件的默認規則對報文進行轉發。從而達到了分流的目的，實現了特定的DHCP服務器對某一類網絡接入設備分配IP地址的需求。

下行中繼：接收從服務器過來的所有DHCP消息，并透傳給標準一級relay。也就是說二級relay對DHCP服務器發來的消息不做任何處理就轉發給標準一級relay。

以上詳細論述了解決方案和系統邏輯結構，二級relay處理DHCP client端報文的代碼流程如下：

4.2 實際應用

下面以廣電網絡接入網部分為例，在接入網處部署、應用我們的二級relay以實現分流的要求。網絡拓撲圖如圖2。

從之前的論述中，我們知道在二級relay的配置文件里會有一系列規則。這些規則規定了某一類設備的DHCP服務器的IP地址。如圖2所示，我們假定配置文件中規定了DHCP Server1是為PC、機頂盒分配IP地址的服務器，DHCP Server2是為cable modem分配IP地址的服務器，而DHCP Server3是為其他網絡接入設備分配IP地址的。也就是說，對這些在配置文件中沒有特定的規則與其相對應的設備，它們的DHCP請求都由二級relay轉發至DHCP Server3。

在如圖2的網絡拓撲中，客戶端從服務器得到網絡配置的基本流程如下：

圖2 實際應用網絡

1. 客戶端廣播發送DHCPDISCOVER報文，CMTS在偵聽到后轉發給二級relay；

2. 二級relay提取出報文的Option60字段，并與配置文件中的規則進行匹配，如果是PC、機頂盒類的設備則將報文轉發給DHCP Server1，如果是cablemodem則轉發給DHCP Server2，如果是配置文件中沒有規則對應的設備，則將它們的報文都轉發給DHCP Server3；

3. 相應的DHCP服務器在收到DHCPDISCOVER報文后，會回復DHCPOFFER報文給二級relay，二級relay透傳給CMTS，再由CMTS透傳給客戶端；

4. 收到DHCPOFFER報文后，客戶端發出DHCPREQUEST報文，CMTS轉發給二級relay，之后的處理等同步驟2；

5. 相應的服務器回復DHCPACK報文，對客戶端的DHCPREQUEST報文予以確認，并透傳至客戶端；

6. 客戶端收到DHCPACK后應再次檢查配置參數( 如通過ARP探測分配的IP地址) ，如果合法則此次配置即告完成，否則回到步驟1再進行一次配置。

在實際應用后發現，按上述流程對客戶端進行網絡配置，能很好地緩解服務器的壓力，并便于運營商管理為不同接入設備提供配置的DHCP服務器。

5.總結

現今，家庭用戶需要IP地址的設備越來越多，而對這類設備多采用DHCP的方式配置網絡參數。這也意味著DHCP客戶端的報文流量在逐漸增加。本文提出并實現了一種加入解析Option60字段功能的中繼代理。通過在實際應用中的檢驗，這種中繼代理能很好地起到為客戶端報文分流的功能。

[1] Droms R. Dynamic Host Configuration Protocol [M]. RFC 2131, 1997.3.

[2] Alexander S, Droms R.DHCP Options and BOOTP Vendor Extensions [M].RFC 2132, 1997.3.

[3] Patrick M.DHCP Relay Agent Information Option [M].RFC 3046, 2001.1.

[4] Wimer W. Clarifications and Extensions for the Bootstrap Protocol [M]. RFC 1542, 1993.10.