專利名稱：同步動(dòng)態(tài)主機(jī)配置協(xié)議中繼地址表與服務(wù)器地址池的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通信技術(shù)領(lǐng)域，具體涉及一種同步動(dòng)態(tài)主機(jī)配置協(xié)議中繼地址表與服務(wù)器地址池的方法。
背景技術(shù)：
如今的網(wǎng)絡(luò)，不管是企業(yè)網(wǎng)還是城域網(wǎng)，規(guī)模都越來越大，節(jié)點(diǎn)數(shù)也越來越多。這樣，就給網(wǎng)絡(luò)管理帶來更大的挑戰(zhàn)，尤其是IP(因特網(wǎng)協(xié)議)地址的管理。在規(guī)模較小的網(wǎng)絡(luò)中，采用靜態(tài)配置IP地址沒有什么麻煩，但對(duì)規(guī)模較大的網(wǎng)絡(luò)，采用靜態(tài)配置IP地址不僅容易出錯(cuò)，造成IP地址沖突，而且會(huì)使配置工作變得非常復(fù)雜，因此產(chǎn)生了DHCP(Dynamic Host Configuration Protocol，動(dòng)態(tài)主機(jī)配置協(xié)議)。DHCP提供了一種動(dòng)態(tài)指定IP地址和配置參數(shù)的機(jī)制。啟用DHCP的計(jì)算機(jī)可以自動(dòng)申請IP地址，不需要手工配置任何網(wǎng)絡(luò)參數(shù)就可以上網(wǎng)，它的出現(xiàn)使得計(jì)算機(jī)上網(wǎng)的配置變得方便容易，而且也簡化了網(wǎng)絡(luò)管理工作。另外DHCP使IP地址可以租用，對(duì)于擁有多臺(tái)計(jì)算機(jī)的大型網(wǎng)絡(luò)來說，每臺(tái)計(jì)算機(jī)擁有一個(gè)IP地址有時(shí)可能是不必要的，因此可以使幾臺(tái)計(jì)算機(jī)分時(shí)租用一個(gè)IP地址，從而節(jié)約了IP地址資源。
DHCP協(xié)議基于一般的client(客戶機(jī))/server(服務(wù)器)模型，即client主動(dòng)發(fā)起請求報(bào)文，server返回相應(yīng)的應(yīng)答報(bào)文。這里的client就是普通的計(jì)算機(jī)，server就是DHCP server，計(jì)算機(jī)啟動(dòng)或申請地址時(shí)向DHCP server發(fā)送地址申請報(bào)文，DHCP server自動(dòng)為client指定IP地址和其它網(wǎng)絡(luò)參數(shù)，并發(fā)送回應(yīng)報(bào)文。由于DHCP client與server交互過程中大多使用廣播報(bào)文，而為了減少網(wǎng)絡(luò)中廣播報(bào)文流量，TCP/IP(傳輸控制協(xié)議/因特網(wǎng)協(xié)議)協(xié)議規(guī)定廣播報(bào)文是不能直接透傳到其他網(wǎng)段的，所以存在DHCP廣播報(bào)文不能跨網(wǎng)段交互的問題。這樣如果DHCP client和server分別在不同網(wǎng)段就無法進(jìn)行交互。
目前，利用DHCP中繼解決上述問題，即利用DHCP中繼在不同網(wǎng)段之間轉(zhuǎn)發(fā)DHCP報(bào)文，從而實(shí)現(xiàn)多個(gè)網(wǎng)絡(luò)共用一個(gè)DHCP server。通常的DHCP中繼是集成在路由器或三層以太網(wǎng)交換機(jī)中的一個(gè)功能子模塊，三層以太網(wǎng)交換機(jī)和路由器一樣也可以配置不同的網(wǎng)段來劃分子網(wǎng)，其DHCP中繼實(shí)現(xiàn)方式相同。DHCP中繼典型組網(wǎng)方式如圖1所示，包括具有DHCP中繼功能的三層交換機(jī)、與其相連的網(wǎng)絡(luò)1中的DHCP服務(wù)器和網(wǎng)絡(luò)2中的DHCP客戶機(jī)。
以三層以太網(wǎng)交換機(jī)作為中繼，其DHCP中繼實(shí)現(xiàn)方式如下參見圖2，正常情況下client申請IP地址成功需要經(jīng)過以下4個(gè)報(bào)文交互過程(1)client主動(dòng)發(fā)出DHCP-discover(DHCP發(fā)現(xiàn))廣播報(bào)文查找可用server；(2)server回應(yīng)提供配置參數(shù)的DHCP-offer(DHCP授權(quán))報(bào)文；(3)client根據(jù)這些參數(shù)發(fā)出DHCP-request(DHCP請求)廣播報(bào)文；(4)server回應(yīng)DHCP-ack(DHCP確認(rèn))報(bào)文，并把該地址從空閑改為已分配狀態(tài)。
client收到DHCP-ack報(bào)文后就可以確認(rèn)動(dòng)態(tài)配置成功。
如果client原來已經(jīng)分配過地址，則可以省略DHCP-discover、DHCP-offer兩個(gè)報(bào)文，直接向server發(fā)送DHCP-request申請?jiān)瓉淼牡刂?，server認(rèn)為該配置可用即回應(yīng)DHCP-ack報(bào)文，否則回應(yīng)DHCP-nak(DHCP否決)報(bào)文。
DHCP中繼用于在不同網(wǎng)絡(luò)之間轉(zhuǎn)發(fā)DHCP報(bào)文，為DHCP廣播報(bào)文提供網(wǎng)段間的轉(zhuǎn)發(fā)功能，使DHCP服務(wù)器為不在其網(wǎng)段內(nèi)的用戶終端提供服務(wù)，從而實(shí)現(xiàn)多個(gè)網(wǎng)絡(luò)共用一個(gè)DHCP服務(wù)器。
DHCP支持三種類型的地址分配(1)自動(dòng)分配方式中DHCP給主機(jī)指定一個(gè)永久的IP地址；
(2)動(dòng)態(tài)分配方式中DHCP給主機(jī)指定一個(gè)有時(shí)間限制的IP地址，到時(shí)間或主機(jī)明確表示放棄這個(gè)地址時(shí)，這個(gè)地址可以被其他的主機(jī)使用；(3)手工分配方式中主機(jī)的IP地址是由網(wǎng)絡(luò)管理員指定的，DHCP只是把指定的IP地址告訴主機(jī)。
在這三種方式中，只有動(dòng)態(tài)分配的方式可以對(duì)已經(jīng)分配給主機(jī)但現(xiàn)在此主機(jī)已經(jīng)不用的IP地址重新加以利用。這樣，在給一臺(tái)臨時(shí)連入網(wǎng)絡(luò)的主機(jī)分配地址或者在一組不需要永久的IP地址的主機(jī)中共享一組有限的IP地址時(shí)，動(dòng)態(tài)分配顯得特別有用。當(dāng)一臺(tái)新主機(jī)要永久的接入一個(gè)網(wǎng)絡(luò)時(shí)，而網(wǎng)絡(luò)的IP地址非常有限，為了將來這臺(tái)主機(jī)被淘汰時(shí)能回收IP地址，這種情況下動(dòng)態(tài)分配也是一個(gè)很好的選擇。
但利用DPCP協(xié)議進(jìn)行動(dòng)態(tài)地址分配也帶來了一個(gè)問題，因?yàn)槟壳癉HCP協(xié)議中沒有考慮如何限制主機(jī)設(shè)置固定IP地址，即不經(jīng)過DHCP申請網(wǎng)絡(luò)IP地址而擅自指定某個(gè)固定IP地址，也就是存在IP地址欺騙的問題。
針對(duì)該問題，中國專利申請125007.3公開了“一種動(dòng)態(tài)地址分配中防止IP地址欺騙的方法”，該方法在DHCP中繼上通過把申請過IP地址的主機(jī)MAC(媒體接入控制)地址和IP地址記錄在一個(gè)動(dòng)態(tài)地址表中，只有在該動(dòng)態(tài)地址表中存在的主機(jī)才會(huì)在交換機(jī)中生成對(duì)應(yīng)的ARP(地址解析協(xié)議)表項(xiàng)，而私自固定設(shè)置IP地址的主機(jī)無法生成ARP表項(xiàng)，也就無法連通外部網(wǎng)絡(luò)。但該方案并沒有揭示如何使該動(dòng)態(tài)地址表與DHCP服務(wù)器的IP地址池保持一致的問題。例如，DHCP服務(wù)器地址池中某個(gè)IP地址租期已經(jīng)過期或被刪除，對(duì)應(yīng)DHCP中繼上的動(dòng)態(tài)地址池就應(yīng)該刪除該項(xiàng)，否則如果把主機(jī)IP地址固定設(shè)為該過期IP地址，則主機(jī)仍然可以上網(wǎng)，也即無法避免IP地址欺騙的問題。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供一種同步動(dòng)態(tài)主機(jī)配置協(xié)議中繼地址表與服務(wù)器地址池的方法，以解決現(xiàn)有技術(shù)方案中不能動(dòng)態(tài)保持DHCP中繼的動(dòng)態(tài)地址表與DHCP服務(wù)器IP地址池同步的問題。
為此，本發(fā)明提供以下技術(shù)方案一種同步動(dòng)態(tài)主機(jī)配置協(xié)議中繼地址表與服務(wù)器地址池的方法，所述方法包括A、所述中繼通過同步動(dòng)態(tài)主機(jī)配置協(xié)議DHCP消息獲取所述服務(wù)器地址池的表項(xiàng)狀態(tài)；B、根據(jù)所述獲取的服務(wù)器地址池的表項(xiàng)狀態(tài)修改所述地址表，使所述地址表中的地址與所述服務(wù)器地址池中已分配的地址一致。
所述步驟A包括A1、所述中繼定時(shí)遍歷所述地址表，依次獲取地址表項(xiàng)中的IP地址；A2、發(fā)送包含所述IP地址的DHCP請求消息到所述服務(wù)器；A3、所述服務(wù)器根據(jù)所述DHCP請求消息向所述中繼發(fā)送回應(yīng)消息；A4、所述中繼根據(jù)所述回應(yīng)消息獲取所述服務(wù)器地址池的表項(xiàng)狀態(tài)。
所述步驟A2包括A21、根據(jù)所述IP地址和所述中繼的媒體接入控制地址構(gòu)造所述DHCP請求消息報(bào)文；A22、將所述DHCP請求消息報(bào)文發(fā)送到所述服務(wù)器。
所述步驟A21包括將所述IP地址作為待檢測地址填充到所述DHCP請求消息報(bào)文的事務(wù)標(biāo)識(shí)字段；將所述中繼的媒體接入控制地址填充到所述DHCP請求消息報(bào)文的客戶機(jī)硬件地址字段。
所述步驟A3包括A31、所述服務(wù)器獲取所述DHCP請求消息中的IP地址；
A32、根據(jù)所述IP地址查詢所述地址池；A33、根據(jù)查詢結(jié)果向所述中繼發(fā)送回應(yīng)消息。
所述步驟A33包括當(dāng)所述IP地址對(duì)應(yīng)的所述地址池中的地址為空閑時(shí)，向所述中繼發(fā)送DHCP確認(rèn)消息；當(dāng)所述IP地址對(duì)應(yīng)的所述地址池中的地址為被占用時(shí)，向所述中繼發(fā)送DHCP否決消息。
所述步驟A4包括A41、如果所述中繼收到的是所述DHCP確認(rèn)消息，則根據(jù)所述DHCP確認(rèn)消息獲取所述待檢測地址；A42、如果所述中繼收到的是所述DHCP否決消息，并且所述DHCP否決消息報(bào)文中的客戶機(jī)硬件地址字段為所述中繼的媒體接入控制地址時(shí)，則正常結(jié)束；A43、如果所述中繼收到的是所述DHCP否決消息，并且所述DHCP否決消息報(bào)文中的客戶機(jī)硬件地址字段不為所述中繼的媒體接入控制地址時(shí)，則進(jìn)行正常的中繼轉(zhuǎn)發(fā)流程。
所述步驟A41包括當(dāng)所述DHCP確認(rèn)消息報(bào)文中的客戶機(jī)硬件地址字段為所述中繼的MAC地址時(shí)，根據(jù)所述DHCP確認(rèn)消息報(bào)文中的事務(wù)ID字段獲取所述待檢測地址；否則，根據(jù)所述DHCP確認(rèn)消息進(jìn)行正常的中繼轉(zhuǎn)發(fā)流程。
所述步驟B包括B1、查詢所述地址表；B2、刪除所述地址表中與所述待檢測地址對(duì)應(yīng)的地址表項(xiàng)。
所述方法還包括當(dāng)所述DHCP確認(rèn)消息報(bào)文中的客戶機(jī)硬件地址字段為所述中繼的MAC地址時(shí)，所述中繼向所述服務(wù)器發(fā)送DHCP釋放消息；所述服務(wù)器根據(jù)所述DHCP釋放消息進(jìn)行對(duì)應(yīng)的操作。
所述中繼集成在路由器或三層以太網(wǎng)交換機(jī)中。
由以上本發(fā)明提供的技術(shù)方案可以看出，本發(fā)明通過在DHCP中繼上模擬DHCP客戶機(jī)向DHCP服務(wù)器申請網(wǎng)絡(luò)地址的方式，獲知DHCP服務(wù)器地址池中各IP地址的分配狀態(tài)，根據(jù)該狀態(tài)就可刪除動(dòng)態(tài)地址表中對(duì)應(yīng)于DHCP服務(wù)器地址池中已經(jīng)空閑的IP地址，保證了該空閑地址不再被未申請用戶使用。依照該方式，通過在DHCP中繼上定時(shí)遍歷動(dòng)態(tài)地址表，對(duì)每一個(gè)地址表項(xiàng)進(jìn)行及時(shí)檢測，保證了DHCP中繼地址池與DHCP服務(wù)器地址池的一致性，從而增強(qiáng)了IP地址的使用安全。


圖1是DHCP中繼的典型組網(wǎng)方式；圖2是現(xiàn)有技術(shù)中DHCP中繼轉(zhuǎn)發(fā)報(bào)文流程；圖3是DHCP報(bào)文格式；圖4是本發(fā)明方法的流程圖；圖5a、圖5b是本發(fā)明方法中DHCP中繼與DHCP服務(wù)器的消息交互流程；圖6是本發(fā)明方法中對(duì)中繼地址表的遍歷檢測流程；圖7是本發(fā)明方法中DHCP中繼對(duì)DHCP服務(wù)器的回應(yīng)消息的處理流程。
具體實(shí)施例方式
本發(fā)明的核心在于在DHCP(動(dòng)態(tài)主機(jī)配置協(xié)議)中繼上模擬DHCP客戶機(jī)向DHCP服務(wù)器申請網(wǎng)絡(luò)地址的方式，獲知DHCP服務(wù)器地址池中各IP地址的分配狀態(tài)，然后根據(jù)該狀態(tài)刪除動(dòng)態(tài)地址表中對(duì)應(yīng)于DHCP服務(wù)器地址池中已經(jīng)空閑的IP地址，使DHCP中繼的動(dòng)態(tài)地址表與DHCP服務(wù)器地址池保持同步狀態(tài)。
為了使本技術(shù)領(lǐng)域的人員更好地理解本發(fā)明方案，下面結(jié)合附圖和實(shí)施方式對(duì)本發(fā)明作進(jìn)一步的詳細(xì)說明。
參照圖3，圖3示出了DHCP報(bào)文格式，其中“消息類型”字段表示當(dāng)前報(bào)文是客戶機(jī)的請求還是服務(wù)器的應(yīng)答，為1時(shí)表示是客戶機(jī)的請求，為2時(shí)表示是服務(wù)器的應(yīng)答。
“硬件地址類型”，“硬件地址長度”字段分別表示客戶機(jī)的網(wǎng)絡(luò)硬件地址類型、長度，如“硬件地址類型”為1，表示客戶機(jī)的網(wǎng)絡(luò)硬件是10MB的以太網(wǎng)類型，“硬件地址長度”為6，表示客戶機(jī)的網(wǎng)絡(luò)硬件地址長度是6bytes(即以太網(wǎng)類型的6bytes的MAC地址)。
“跳數(shù)”字段表示當(dāng)前的DHCP報(bào)文經(jīng)過的DHCP中繼的數(shù)目，類似于IP頭中的跳數(shù)字段，但含義完全不同，客戶機(jī)或服務(wù)器發(fā)出DHCP報(bào)文時(shí)，此字段都初始化為0，每經(jīng)過一個(gè)DHCP中繼，此字段就會(huì)加1，此字段的作用是限制DHCP報(bào)文不要經(jīng)過太多的DHCP中繼，協(xié)議規(guī)定，當(dāng)“跳數(shù)”大于4(也有規(guī)定為16)時(shí)，這個(gè)DHCP報(bào)文就不能再進(jìn)行處理，而是丟棄。
“事務(wù)ID(標(biāo)識(shí))”字段客戶機(jī)每次發(fā)送DHCP請求報(bào)文時(shí)選擇的隨機(jī)數(shù)，由客戶機(jī)和服務(wù)器用來聯(lián)系消息和響應(yīng)請求，匹配服務(wù)器的響應(yīng)報(bào)文是對(duì)哪個(gè)請求報(bào)文的響應(yīng)。服務(wù)器在應(yīng)答報(bào)文中必須填上相同的事務(wù)ID值，用于確認(rèn)請求/應(yīng)答是否匹配。
“秒數(shù)”字段用來表示客戶機(jī)開始DHCP請求后的時(shí)間流逝秒數(shù)，此字段一般沒有多大意義，最初設(shè)計(jì)此字段是為了讓DHCP服務(wù)器在繁忙時(shí)，優(yōu)先處理此字段大的DHCP請求。
“標(biāo)志”字段在DHCP協(xié)議中只使用了其左邊的最高位，作為廣播響應(yīng)標(biāo)識(shí)位。
“客戶機(jī)IP地址”字段表示客戶機(jī)自己的IP地址。可以是服務(wù)器分配給客戶機(jī)的IP地址，也可以是客戶機(jī)已有的IP地址。
“你的IP地址”字段表示服務(wù)器分配給客戶機(jī)的IP地址。當(dāng)DHCP服務(wù)器響應(yīng)客戶機(jī)的DHCP請求時(shí)，將把分配給客戶機(jī)的IP地址填入此字段。
“服務(wù)器IP地址”字段表示客戶機(jī)獲取啟動(dòng)配置信息的服務(wù)器IP地址，一般是TFTP(簡單文件傳輸協(xié)議)服務(wù)器的IP地址。
“中繼IP地址”字段記錄第一個(gè)DHCP中繼代理的IP地址。當(dāng)客戶機(jī)發(fā)出DHCP請求報(bào)文后，如果網(wǎng)絡(luò)中存在DHCP中繼，則第一個(gè)DHCP中繼轉(zhuǎn)發(fā)這個(gè)DHCP請求報(bào)文時(shí)，就會(huì)把自己的IP地址填入此字段(隨后的DHCP中繼將不再改寫此字段，只是把跳數(shù)加1)。DHCP服務(wù)器將會(huì)根據(jù)此字段為用戶分配IP地址，并把響應(yīng)報(bào)文轉(zhuǎn)發(fā)給此DHCP中繼代理，由DHCP中繼代理再轉(zhuǎn)發(fā)給客戶機(jī)。
“客戶機(jī)硬件地址”字段記錄客戶機(jī)的實(shí)際硬件地址內(nèi)容。當(dāng)客戶機(jī)發(fā)出DHCP請求報(bào)文時(shí)，將把自己的網(wǎng)卡硬件地址填入此字段，DHCP服務(wù)器一般都會(huì)使用此字段來唯一標(biāo)識(shí)一個(gè)客戶機(jī)。而且此字段與前面的“硬件地址類型”、“硬件地址長度”字段必須一致。如當(dāng)“硬件地址類型”、“硬件地址長度”分別為1和6時(shí)，此字段必須填入6bytes的以太網(wǎng)MAC(媒體接入控制)地址。
“服務(wù)器的主機(jī)名”字段記錄客戶機(jī)獲取啟動(dòng)配置信息的服務(wù)器名字。此字段由DHCP服務(wù)器填寫，而且是可選的，如果填寫，必須是一個(gè)以0結(jié)尾的字符串。
“啟動(dòng)文件名”字段記錄客戶機(jī)的啟動(dòng)配置文件名。此字段由DHCP服務(wù)器填寫，而且是可選的，如果填寫，必須是一個(gè)以0結(jié)尾的字符串。
“選項(xiàng)”字段此字段中包含了大量可選的終端初始配置信息和網(wǎng)絡(luò)配置信息，如決定終端的IP特性配置信息、域名信息、標(biāo)識(shí)終端的特殊信息、終端的默認(rèn)網(wǎng)關(guān)IP地址、DNS(域名系統(tǒng))服務(wù)器的IP地址、WINS(Windows InternetName Server)服務(wù)器的IP地址、用戶使用IP地址的有效租期等信息。
本發(fā)明方法中主要通過上述“事務(wù)ID”字段、“客戶機(jī)硬件地址”字段及“中繼IP地址”字段承載所需信息，實(shí)現(xiàn)DHCP中繼對(duì)DHCP服務(wù)器地址池的查詢。
本技術(shù)領(lǐng)域人員知道，DHCP協(xié)議采用CLIENT-SERVER方式進(jìn)行交互，其報(bào)文格式共有8種，由“選項(xiàng)”字段中的“DHCP message type”選項(xiàng)的value值來確定，具體含義如下1.DHCP-discover(發(fā)現(xiàn))類型值為0x01，此為客戶機(jī)開始DHCP過程的第一個(gè)報(bào)文；2.DHCP-offer(授權(quán))類型值為0x02此為服務(wù)器對(duì)DHCP-discover報(bào)文的響應(yīng)；3.DHCP-request(請求)類型值為0x03，此報(bào)文是客戶機(jī)開始DHCP過程中對(duì)服務(wù)器的DHCP-offer報(bào)文的回應(yīng)，或者是客戶機(jī)續(xù)延IP地址租期時(shí)發(fā)出的報(bào)文；4.DHCP-decline(拒絕)類型值為0x04，當(dāng)客戶機(jī)發(fā)現(xiàn)服務(wù)器分配給它的IP地址無法使用，如IP地址沖突時(shí)，將發(fā)出此報(bào)文，通知服務(wù)器禁止使用IP地址；5.DHCP-ack(確認(rèn))類型值為0x05，服務(wù)器對(duì)客戶機(jī)的DHCP-request報(bào)文的確認(rèn)響應(yīng)報(bào)文，客戶機(jī)收到此報(bào)文后，才真正獲得了IP地址和相關(guān)的配置信息；6.DHCP-nak(否決)類型值為0x06，服務(wù)器對(duì)客戶機(jī)的DHCP-request報(bào)文的拒絕響應(yīng)報(bào)文，客戶機(jī)收到此報(bào)文后，一般會(huì)重新開始新的DHCP過程。
7.DHCP-release(釋放)類型值為0x07，客戶機(jī)主動(dòng)釋放服務(wù)器分配給它的IP地址的報(bào)文，當(dāng)服務(wù)器收到此報(bào)文后，就可以回收這個(gè)IP地址，能夠分配給其他的客戶機(jī)。
8.DHCP-inform(信息)類型值為0x08，客戶機(jī)已經(jīng)獲得了IP地址，發(fā)送此報(bào)文，只是為了從DHCP服務(wù)器處獲取其他的一些網(wǎng)絡(luò)配置信息，如路由IP，DNS IP等。
本發(fā)明就是在DHCP中繼上模擬DHCP客戶機(jī)向DHCP服務(wù)器申請網(wǎng)絡(luò)地址。報(bào)文應(yīng)答分為兩種情況，如果申請的網(wǎng)絡(luò)地址在服務(wù)器的地址池中已經(jīng)空閑，則可以申請成功，并且服務(wù)器會(huì)返回一個(gè)DHCP確認(rèn)報(bào)文；如果申請的網(wǎng)絡(luò)地址在服務(wù)器地址池中被占用，則服務(wù)器會(huì)返回一個(gè)DHCP否決報(bào)文。這樣，DHCP中繼根據(jù)收到的服務(wù)器的回應(yīng)就可以檢測某個(gè)網(wǎng)絡(luò)地址在服務(wù)器地址池中的分配狀態(tài)。具體地址信息的承載是通過DHCP報(bào)文中的“事務(wù)ID”字段、“客戶機(jī)硬件地址”字段來實(shí)現(xiàn)的。下面將結(jié)合圖4對(duì)本發(fā)明方法作詳細(xì)說明。
參照圖4，圖4是本發(fā)明方法的流程圖，包括以下步驟首先，在步驟401由DHCP中繼定時(shí)遍歷其地址表，依次獲取地址表項(xiàng)中的IP地址；然后，進(jìn)到步驟402根據(jù)IP地址和中繼的MAC地址構(gòu)造DHCP請求消息報(bào)文。
前面已經(jīng)提到，本發(fā)明中利用DHCP報(bào)文中的事務(wù)ID字段和客戶機(jī)硬件地址字段承載查詢DHCP服務(wù)器地址池時(shí)所需的信息，具體承載信息如下將獲取的IP地址作為待檢測地址填充到DHCP請求消息報(bào)文的事務(wù)ID字段；將DHCP中繼的MAC地址填充到DHCP請求消息報(bào)文的客戶機(jī)硬件地址字段。
因?yàn)樵贒HCP中繼利用DHCP消息對(duì)服務(wù)器進(jìn)行地址池表項(xiàng)狀態(tài)查詢的同時(shí)，還會(huì)有其他客戶機(jī)的正常DHCP轉(zhuǎn)發(fā)報(bào)文，因此就需要DHCP中繼將這種檢測報(bào)文與正常的轉(zhuǎn)發(fā)報(bào)文區(qū)別開。也就是通過檢查回應(yīng)報(bào)文中的事務(wù)ID字段和客戶機(jī)硬件地址字段來判斷該報(bào)文是否為服務(wù)器的檢測回應(yīng)。
在發(fā)起的request(請求)報(bào)文客戶機(jī)硬件地址字段中填入DHCP中繼(即交換機(jī)或路由器)的硬件MAC地址，這樣也可以避免與網(wǎng)絡(luò)上的真實(shí)地址發(fā)生沖突，服務(wù)器在回應(yīng)的ack(確認(rèn))或nak(否決)報(bào)文中也會(huì)填入相同的值。DHCP中繼將收到ack或nak報(bào)文中的硬件地址域作為判斷該報(bào)文是否是檢測回應(yīng)的首要條件；同樣如果在發(fā)起的request報(bào)文的事務(wù)ID里填入當(dāng)前檢測地址項(xiàng)的IP地址，服務(wù)器在回應(yīng)的ack或nak報(bào)文中也會(huì)填入相同的值。DHCP中繼將收到ack或nak報(bào)文中的事務(wù)ID字段作為判斷該報(bào)文是否是檢測回應(yīng)的第二個(gè)條件。
因?yàn)橛布刂肥枪潭ú蛔兊?，容易受到欺騙報(bào)文的攻擊，而第二個(gè)條件中當(dāng)前檢測地址項(xiàng)的IP地址是在不斷變化的，攻擊者無法仿冒，從而也大大增強(qiáng)了該檢測功能實(shí)現(xiàn)上的安全性。
步驟403將DHCP請求消息報(bào)文發(fā)送到DHCP服務(wù)器。
DHCP服務(wù)器收到DHCP請求消息后，進(jìn)到以下步驟處理首先，在步驟404服務(wù)器獲取DHCP請求消息中的IP地址。
進(jìn)到步驟405根據(jù)IP地址查詢地址池。
然后，進(jìn)到步驟406根據(jù)查詢結(jié)果向中繼發(fā)送回應(yīng)消息。
因?yàn)榈刂烦刂邪ㄔ试S接入服務(wù)器的所有IP地址，這些地址有些可能已分配給某些客戶機(jī)使用，有些還未分配或是客戶機(jī)的使用租期到期被收回，即這些地址處于空閑狀態(tài)。在地址池中，對(duì)每個(gè)表項(xiàng)都標(biāo)明了該表項(xiàng)中IP地址的當(dāng)前使用狀態(tài)。因此，服務(wù)器根據(jù)獲取的DHCP請求消息中的IP地址對(duì)地址池的查詢結(jié)果有兩種情況該IP地址被占用或空閑。針對(duì)這兩種情況，服務(wù)器向中繼返回不同的回應(yīng)消息。
(1)當(dāng)該IP地址對(duì)應(yīng)的地址池中的地址為空閑時(shí)，向中繼發(fā)送DHCP確認(rèn)消息；
(2)當(dāng)該IP地址對(duì)應(yīng)的地址池中的地址為被占用時(shí)，向中繼發(fā)送DHCP否決消息。
步驟407中繼根據(jù)回應(yīng)消息獲取服務(wù)器地址池的表項(xiàng)狀態(tài)。
針對(duì)上述不同的回應(yīng)消息，中繼的處理也不同如果中繼收到的是DHCP確認(rèn)消息，則根據(jù)DHCP確認(rèn)消息獲取待檢測地址；如果中繼收到的是DHCP否決消息，則正常結(jié)束。
在前面步驟402中已經(jīng)說明在中繼發(fā)起的DHCP請求消息中，客戶機(jī)硬件地址字段中填入了DHCP中繼的硬件MAC地址，在事務(wù)ID字段中填入了當(dāng)前檢測地址項(xiàng)的IP地址。服務(wù)器在回應(yīng)的確認(rèn)或否決報(bào)文中也會(huì)填入相同的值。這樣，DHCP中繼根據(jù)收到的確認(rèn)或否決報(bào)文中的客戶機(jī)硬件地址字段就可知道是否為查詢的回應(yīng)消息，根據(jù)事務(wù)ID字段獲知查詢的IP地址。如果DHCP確認(rèn)消息報(bào)文中的客戶機(jī)硬件地址字段為中繼的MAC地址，則根據(jù)DHCP確認(rèn)消息報(bào)文中的事務(wù)ID字段獲取待檢測地址；否則，根據(jù)DHCP確認(rèn)消息進(jìn)行對(duì)應(yīng)的轉(zhuǎn)發(fā)流程。
進(jìn)到步驟408DHCP中繼根據(jù)所述待檢測地址查詢地址表。
然后，進(jìn)到步驟409刪除地址表中與待檢測地址對(duì)應(yīng)的地址表項(xiàng)。
在上述過程中，如果服務(wù)器向中繼返回的是確認(rèn)消息，則說明模擬申請地址成功，服務(wù)器已為該申請分配了IP地址，該IP地址就是中繼發(fā)送的請求消息中的事務(wù)ID字段中填充的地址，也就是上面所說的待檢測地址。因?yàn)橹欣^只是借用DHCP協(xié)議，模擬DHCP客戶機(jī)向DHCP服務(wù)器申請網(wǎng)絡(luò)地址，但其真正的目的是對(duì)申請的IP地址進(jìn)行狀態(tài)檢測。因此，在這種情況下，中繼還必須主動(dòng)發(fā)送一個(gè)DHCP釋放報(bào)文，以恢復(fù)DHCP服務(wù)器上對(duì)應(yīng)的該地址。服務(wù)器根據(jù)DHCP釋放消息進(jìn)行對(duì)應(yīng)的操作，即恢復(fù)該地址為空閑狀態(tài)。
例如，在DHCP中繼的地址表中存在IP地址202.110.11.2，利用本發(fā)明對(duì)該地址進(jìn)行檢測。其在地址池中為不同狀態(tài)時(shí)的報(bào)文應(yīng)答流程分別如圖5a和圖5b所示。
參照圖5a所示該地址為空閑時(shí)報(bào)文的應(yīng)答流程，主要有以下消息交互過程1.DHCP中繼發(fā)送請求消息，該消息中包含待檢測地址202.110.11.2；2.DHCP服務(wù)器收到請求消息后，檢測地址202.110.11.2在服務(wù)器地址池中為空閑狀態(tài)，分配該地址，向DHCP中繼回送確認(rèn)消息；3.DHCP中繼收到確認(rèn)消息后，發(fā)送釋放消息，該消息中包括需要釋放的IP地址202.110.11.2。DHCP服務(wù)器會(huì)根據(jù)該消息進(jìn)行對(duì)應(yīng)的操作。
參照圖5b所示該地址為已分配時(shí)報(bào)文的應(yīng)答流程，主要有以下消息交互過程1.DHCP中繼發(fā)送請求消息，該消息中包含待檢測地址202.110.11.2；2.DHCP服務(wù)器收到請求消息后，檢測地址202.110.11.2在服務(wù)器地址池中為已分配狀態(tài)，向DHCP中繼回送否決消息。DHCP收到否決消息后，正常結(jié)束。
因?yàn)樵贒HCP中繼的動(dòng)態(tài)地址表中會(huì)有多個(gè)地址表項(xiàng)，為了保持地址表與地址池中已分配地址的一致，就需要對(duì)每一個(gè)地址表項(xiàng)都進(jìn)行檢測，通過在DHCP中繼上定時(shí)遍歷該地址表來實(shí)現(xiàn)。
考慮到服務(wù)器回應(yīng)的確認(rèn)報(bào)文或否決報(bào)文有可能會(huì)丟失，所以為了使每一個(gè)地址表項(xiàng)的檢測都能收到回應(yīng)，需要對(duì)前一個(gè)地址表項(xiàng)是否接收到回應(yīng)進(jìn)行檢查，如果沒有收到回應(yīng)則仍然處理上一個(gè)表項(xiàng)。檢測的定時(shí)時(shí)間由定時(shí)器來實(shí)現(xiàn)。
對(duì)地址表項(xiàng)進(jìn)行遍歷檢測的流程如圖6所示首先，在步驟601定時(shí)器到時(shí)后，進(jìn)到步驟602，判斷當(dāng)前處理的地址表項(xiàng)狀態(tài)是否還在等待回應(yīng)；如果是，則進(jìn)到步驟604，發(fā)送request檢測報(bào)文，繼續(xù)檢測當(dāng)前等待回應(yīng)的表項(xiàng)，并標(biāo)志當(dāng)前表項(xiàng)狀態(tài)為等待狀態(tài)。然后，到步驟605，等待定時(shí)器到時(shí)后，再返回601，進(jìn)行下一輪檢測。
如果不是，則進(jìn)到步驟603，取地址表中的下一個(gè)表項(xiàng)作為當(dāng)前處理項(xiàng)，然后，進(jìn)到步驟604，發(fā)送request檢測報(bào)文，繼續(xù)檢測當(dāng)前等待回應(yīng)的表項(xiàng)，并標(biāo)志當(dāng)前表項(xiàng)狀態(tài)為等待狀態(tài)。然后，到步驟605，等待定時(shí)器到時(shí)后，再返回601，進(jìn)行下一輪檢測。
在DHCP中繼模擬DHCP客戶機(jī)向DHCP服務(wù)器申請網(wǎng)絡(luò)地址，對(duì)地址表項(xiàng)進(jìn)行檢測的同時(shí)，DHCP中繼還會(huì)轉(zhuǎn)發(fā)實(shí)際DHCP客戶機(jī)與DHCP服務(wù)器的DHCP報(bào)文，因此，DHCP中繼會(huì)從DHCP服務(wù)器接收到對(duì)檢測報(bào)文的回應(yīng)消息及對(duì)實(shí)際客戶機(jī)申請地址的回應(yīng)消息，此時(shí)，需要對(duì)這些消息進(jìn)行判斷，分別做出不同的處理，處理過程如圖7所示在步驟S01DHCP中繼接收報(bào)文，接收的報(bào)文可能有以下三種情況(1)ack(確認(rèn))報(bào)文；(2)nak(否決)報(bào)文；(3)DHCP服務(wù)器發(fā)送的其他報(bào)文。
DHCP中繼對(duì)這三種不同報(bào)文的處理如下當(dāng)收到ack報(bào)文時(shí)，進(jìn)到步驟S11，判斷收到的ack報(bào)文是否為服務(wù)器對(duì)檢測報(bào)文的應(yīng)答，如果是，則進(jìn)到步驟S12，向服務(wù)器發(fā)送release報(bào)文，標(biāo)記當(dāng)前處理表項(xiàng)結(jié)束等待，并刪除中繼上對(duì)應(yīng)的動(dòng)態(tài)地址表項(xiàng)。然后，進(jìn)到步驟S13，等待接收下一個(gè)報(bào)文。
當(dāng)收到nak報(bào)文時(shí)，進(jìn)到步驟S21，判斷收到的nak報(bào)文是否為服務(wù)器對(duì)檢測報(bào)文的應(yīng)答，如果是，則進(jìn)到步驟S22，標(biāo)記當(dāng)前處理表項(xiàng)結(jié)束等待。然后，進(jìn)到步驟S13，等待接收下一個(gè)報(bào)文。
當(dāng)收到其他報(bào)文時(shí)，進(jìn)到步驟S02，進(jìn)行中繼的正常轉(zhuǎn)發(fā)流程。
上述DHCP中繼可以集成在路由器或三層以太網(wǎng)交換機(jī)中。其對(duì)DHCP服務(wù)器地址池的查詢方式相同。
上述實(shí)施例描述了在DHCP中繼上實(shí)現(xiàn)地址表與DHCP服務(wù)器地址池分配地址保持一致的實(shí)現(xiàn)過程，應(yīng)該知道，稍加變化，即可將本發(fā)明用于多個(gè)DHCP服務(wù)器主備之間進(jìn)行分配地址的同步，或者其他需要查詢DHCP服務(wù)器地址池的應(yīng)用中。
雖然通過實(shí)施例描繪了本發(fā)明，本領(lǐng)域普通技術(shù)人員知道，本發(fā)明有許多變形和變化而不脫離本發(fā)明的精神，希望所附的權(quán)利要求包括這些變形和變化而不脫離本發(fā)明的精神。
權(quán)利要求
1.一種同步動(dòng)態(tài)主機(jī)配置協(xié)議中繼地址表與服務(wù)器地址池的方法，其特征在于，所述方法包括A、所述中繼通過同步動(dòng)態(tài)主機(jī)配置協(xié)議DHCP消息獲取所述服務(wù)器地址池的表項(xiàng)狀態(tài)；B、根據(jù)所述獲取的服務(wù)器地址池的表項(xiàng)狀態(tài)修改所述地址表，使所述地址表中的地址與所述服務(wù)器地址池中已分配的地址一致。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟A包括A1、所述中繼定時(shí)遍歷所述地址表，依次獲取地址表項(xiàng)中的IP地址；A2、發(fā)送包含所述IP地址的DHCP請求消息到所述服務(wù)器；A3、所述服務(wù)器根據(jù)所述DHCP請求消息向所述中繼發(fā)送回應(yīng)消息；A4、所述中繼根據(jù)所述回應(yīng)消息獲取所述服務(wù)器地址池的表項(xiàng)狀態(tài)。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述步驟A2包括A21、根據(jù)所述IP地址和所述中繼的媒體接入控制地址構(gòu)造所述DHCP請求消息報(bào)文；A22、將所述DHCP請求消息報(bào)文發(fā)送到所述服務(wù)器。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述步驟A21包括將所述IP地址作為待檢測地址填充到所述DHCP請求消息報(bào)文的事務(wù)標(biāo)識(shí)字段；將所述中繼的媒體接入控制地址填充到所述DHCP請求消息報(bào)文的客戶機(jī)硬件地址字段。
5.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述步驟A3包括A31、所述服務(wù)器獲取所述DHCP請求消息中的IP地址；A32、根據(jù)所述IP地址查詢所述地址池；A33、根據(jù)查詢結(jié)果向所述中繼發(fā)送回應(yīng)消息。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，所述步驟A33包括當(dāng)所述IP地址對(duì)應(yīng)的所述地址池中的地址為空閑時(shí)，向所述中繼發(fā)送DHCP確認(rèn)消息；當(dāng)所述IP地址對(duì)應(yīng)的所述地址池中的地址為被占用時(shí)，向所述中繼發(fā)送DHCP否決消息。
7.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述步驟A4包括A41、如果所述中繼收到的是所述DHCP確認(rèn)消息，則根據(jù)所述DHCP確認(rèn)消息獲取所述待檢測地址；A42、如果所述中繼收到的是所述DHCP否決消息，并且所述DHCP否決消息報(bào)文中的客戶機(jī)硬件地址字段為所述中繼的媒體接入控制地址時(shí)，則正常結(jié)束；A43、如果所述中繼收到的是所述DHCP否決消息，并且所述DHCP否決消息報(bào)文中的客戶機(jī)硬件地址字段不為所述中繼的媒體接入控制地址時(shí)，則進(jìn)行正常的中繼轉(zhuǎn)發(fā)流程。
8.根據(jù)權(quán)利要求7所述的方法，其特征在于，所述步驟A41包括當(dāng)所述DHCP確認(rèn)消息報(bào)文中的客戶機(jī)硬件地址字段為所述中繼的媒體接入控制地址時(shí)，根據(jù)所述DHCP確認(rèn)消息報(bào)文中的事務(wù)ID字段獲取所述待檢測地址；否則，根據(jù)所述DHCP確認(rèn)消息進(jìn)行正常的中繼轉(zhuǎn)發(fā)流程。
9.根據(jù)權(quán)利要求4所述的方法，其特征在于，所述步驟B包括B1、查詢所述地址表；B2、刪除所述地址表中與所述待檢測地址對(duì)應(yīng)的地址表項(xiàng)。
10.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述方法還包括當(dāng)所述DHCP確認(rèn)消息報(bào)文中的客戶機(jī)硬件地址字段為所述中繼的媒體接入控制地址時(shí)，所述中繼向所述服務(wù)器發(fā)送DHCP釋放消息；所述服務(wù)器根據(jù)所述DHCP釋放消息進(jìn)行對(duì)應(yīng)的操作。
11.根據(jù)權(quán)利要求1至10任一項(xiàng)所述的方法，其特征在于，所述中繼集成在路由器或三層以太網(wǎng)交換機(jī)中。
全文摘要
本發(fā)明公開了一種同步動(dòng)態(tài)主機(jī)配置協(xié)議中繼地址表與服務(wù)器地址池的方法，所述方法包括中繼通過同步動(dòng)態(tài)主機(jī)配置協(xié)議DHCP消息獲取服務(wù)器地址池的表項(xiàng)狀態(tài)；根據(jù)獲取的服務(wù)器地址池的表項(xiàng)狀態(tài)修改所述地址表，使所述地址表中的地址與所述服務(wù)器地址池中已分配的地址一致。利用本發(fā)明，可以實(shí)現(xiàn)在DHCP中繼上查詢DHCP服務(wù)器地址池中IP地址的狀態(tài)，使DHCP中繼地址表與DHCP服務(wù)器地址池保持同步，從而有效地限制未經(jīng)DHCP申請或已過租期的IP地址的使用，保證網(wǎng)絡(luò)管理的安全。
文檔編號(hào)H04L29/06GK1738269SQ20041005820
公開日2006年2月22日 申請日期2004年8月17日 優(yōu)先權(quán)日2004年8月17日
發(fā)明者修亦宏 申請人:杭州華為三康技術(shù)有限公司