專利名稱：一種IPv6網(wǎng)絡中實現(xiàn)動態(tài)域名更新的方法
技術領域：
本發(fā)明涉及一種IPv6網(wǎng)絡中實現(xiàn)動態(tài)域名更新的方法，屬于通信技術領域。
背景技術：
動態(tài)域名解析(DDNS)的實現(xiàn)分為兩個方面，他們是域名系統(tǒng)(DNS)和動態(tài)主機配置協(xié)議(DHCP)。
DNS全稱是域名系統(tǒng)(Domain Name System)，它于1984年由在美國南加州大學信息科學所負責設計新網(wǎng)絡體系結構的Paul Mockapetris提出。DNS的原始描述是通過RFC882和883，后來被RFC1034和1035取代。實際上，DNS是一個分布式數(shù)據(jù)庫，它允許對整個數(shù)據(jù)庫的各個部分進行本地控制。同時，整個網(wǎng)絡也能通過客戶-服務器方式訪問每個部分的數(shù)據(jù)。DNS首先將整個網(wǎng)絡分成了若干個頂級域名，每個頂級域名再分成若干個二級域名，這樣下去整個網(wǎng)絡就形成了一個類似于樹型的結構。
如圖2所示，DNS樹上的每一個節(jié)點都有一個標識(Label)，根節(jié)點的標識是″空″(即長度為0)，其它節(jié)點的標識的長度在1到63字節(jié)之間。一個節(jié)點的域名是由從這個節(jié)點到根節(jié)點的路徑上的所有標識從左到右順序排列組成的，標識之間用″.″分隔，例如bjtu.edu.cn。每個域都是其上級域的子域(SubDomain)，比如″.edu.cn″是″.cn″的子域，而″bjtu.edu.cn″既是″edu.cn″的子域，同時也是″.cn″的子域。
國際化組織IETF在DNS上設有兩個小組，域名系統(tǒng)運行工作組(Domain NameSystem Operations working group)，DNS擴展工作組(DNS Extensions workinggroup)。分別就DNS系統(tǒng)和區(qū)域的管理、DNS系統(tǒng)中的服務器和服務器之間、客戶和服務器之間的通信數(shù)據(jù)格式和處理制定標準?，F(xiàn)在仍有多篇草案在討論之中，內(nèi)容涉及DNS的安全、編碼、與IPv6的結合等方面。上面提到的動態(tài)域名系統(tǒng)(DDNS)就是在RFC2136中定義的。
可以說IPv4下的DDNS系統(tǒng)已經(jīng)非常成熟，從今天的互聯(lián)網(wǎng)爆炸性增長就可窺一斑，網(wǎng)絡域名數(shù)以億計，域名服務到處都有。DDNS研究的重點已經(jīng)移到了IPv6上，涉及地址支持、傳輸、管理運行等。國內(nèi)的研究狀況與國外相似。
DHCP的全稱是動態(tài)主機配置協(xié)議(Dynamic Host Configuration Protocol)，由IETF設計，目的就是為了減輕TCP/IP網(wǎng)絡的規(guī)劃、管理和維護的負擔，解決IP地址空間缺乏問題。運行DHCP的服務器把TCP/IP網(wǎng)絡設置集中起來，動態(tài)處理工作站IP地址的配置，用DHCP租約和預置的IP地址相聯(lián)系，DHCP租約提供了自動在TCP/IP網(wǎng)絡上安全地分配和租用IP地址的機制，實現(xiàn)IP地址的集中式管理，基本上不需要網(wǎng)絡管理人員的人為干預。而且，DHCP本身被設計成BOOTP(自舉協(xié)議)的擴展，支持需要網(wǎng)絡配置信息的無盤工作站，對需要固定IP的系統(tǒng)也提供了相應支持。
IETF在DHCP上設有動態(tài)主機配置工作組(Dynamic Host Configurationworking group)。研究內(nèi)容包括IPv6的DHCP、NIS、對于不同設備的擴展等。IPv6的DHCP是現(xiàn)在的研究熱點，涉及DHCP實現(xiàn)，時間配置，雙棧等。國內(nèi)這方面的研究較少，還主要集中在IPv4方面。
動態(tài)域名解析系統(tǒng)(DDNS)一般由兩部分構成。第一部分是DNS服務器端程序，位于DNS服務商的主機上。另一部分是DHCP服務器和客戶端程序，運行在DHCP服務器主機和廣大用戶的主機上。在每次用戶連接網(wǎng)絡的時候，DHCP服務器程序就會通過信息傳遞，將動態(tài)IP地址分配給運行DHCP客戶端程序的主機，同時DHCP服務器通過信息交互獲取客戶端主機的域名，然后DHCP服務器把該主機的動態(tài)IP地址傳送給位于服務商主機上的DNS服務器程序，DNS服務器程序負責提供DNS服務并實現(xiàn)動態(tài)域名解析服務，收到客戶端通知后，服務器程序立即更新數(shù)據(jù)，將新的IP地址和客戶端主機域名綁定，這樣就完成了動態(tài)域名解析的服務。別人也就可以通過域名訪問用戶的主機了。當用戶下線時，DNS要停止該域名的解析服務，以免因為同一個IP地址重復利用而引起混亂。
與本發(fā)明相關的現(xiàn)有技術，IPv4網(wǎng)絡中實現(xiàn)動態(tài)域名解析的方法，現(xiàn)有技術的技術方案目前流行的DDNS解決方案是針對IPv4的，它是通過DNS程序軟件與DHCPv4程序軟件的交互完成的。
DHCPv4程序的運行步驟DHCPv4的工作原理比較簡單，一共有7種報文(message)類型，不同的工作步驟由不同的報文類型承擔。
第一步，DHCP客戶端啟動后會首先以廣播形式發(fā)出DHCPDISCOVER報文到網(wǎng)絡上，以便查找一臺能夠提供IP地址的DHCP服務器。
第二步，當網(wǎng)絡上的DHCP服務器收到DHCP客戶端的DHCPDISCOVER報文后，它就是由IP池中挑選一個還沒有出租的IP地址，然后利用廣播的方式提供給DHCP客戶端。
第三步，當DHCP客戶端挑選好第一個收到的DHCPOFFER報文后，它就利用廣播的方式，響應一個DHCPREQUEST報文給DHCP服務器。這一步的作用是通知網(wǎng)絡上到底哪臺DHCP服務器被我選中了，服務器會檢查收到的DHCPREQUEST報文，如果其中所含的地址與自己所提供的一致，證明客戶選擇了這臺服務器，否則說明自己提供的地址被拒絕了。
第四步，DHCP服務器收到DHCP客戶端的要求IP地址的DHCPREQUEST報文后，就會以廣播的方式給DHCP客戶端送出DHCPPACK確認報文，確認信息里包含著IP地址、子網(wǎng)掩碼、DNS地址等信息。這一步的作用是確認，如果因為某些原因不能向客戶提供這個地址，服務器就向客戶發(fā)出DHCPNAK報文。
第五步，客戶收到DHCPPACK確認報文后，檢查內(nèi)部的地址與租期，如果覺得有問題，則發(fā)送DHCPDECLINE報文拒絕這個地址，然后回到第一步重新開始。如果收到的是DHCPNAK報文則直接回到第一步。
第六步，客戶端可以在租期到期之前發(fā)送DHCPRELEASE報文釋放地址。
另外，客戶下一次可以直接申請獲得相同的IP地址，省去了前兩步，直接發(fā)送DHCPREQUEST報文，其中包含自己以前用過的IP地址。如果原來的那臺服務器收到，則會識別出是以前的老客戶，如果以前的地址還未被使用，則用DHCPPACK報文響應，如果不是原來的服務器收到或地址已被使用，則用DHCPNAK報文回復?？蛻羰盏紻HCPPACK報文后，重復第五步；收到DHCPNAK報文后重復第一步。
以上就是DHCPv4完整的工作步驟。在DHCPv4服務器完成了對客戶主機的IPv4地址分配之后，會向DNS服務器發(fā)出更新報文，在rfc2136中規(guī)定了這種更新報文的格式，DNS服務器收到更新報文會加以分析，如果更新成功會向DHCPv4服務器回復確認報文，以表示更新成功。更新報文分為正向更新報文和反向更新報文兩種，每種報文如果更新成功DHCPv4服務器都會收到來自DNS服務器的確認回復。
當然以上所有的操作都要在實現(xiàn)DNS功能的代碼bind-9.2.3的配置文件named.conf和實現(xiàn)DHCP功能的代碼dhcp-3.0.1的配置文件dhcpd.conf、dhclient.conf中做相應的設置才能成功。
這樣就在IPv4地址條件下實現(xiàn)了動態(tài)域名解析(DDNS)。
現(xiàn)有技術的缺點；以上這種技術最大的缺點就是受到了IPv4地址資源有限這個問題的限制。
隨著IP業(yè)務的迅速增長，IP網(wǎng)絡上應用的不斷增加，原有的IP網(wǎng)越來越顯得力不從心。IP網(wǎng)絡正在向下一代網(wǎng)絡演進。其網(wǎng)絡協(xié)議也應產(chǎn)生重大變化。目前使用的IP協(xié)議，IPv4是70年代制定的協(xié)議，隨著全球IP網(wǎng)絡規(guī)模的不斷擴大和用戶數(shù)的迅速增長，IPv4協(xié)議已經(jīng)不能適應發(fā)展的需要。IPv4采用32位地址長度，只有大約43億個地址，估計在2005～2010年間將被分配完畢，這勢必影響互聯(lián)網(wǎng)的普及和深化發(fā)展，擴大地址空間已經(jīng)成為互聯(lián)網(wǎng)發(fā)展的當務之急。90年代初，有關專家就預見到IP協(xié)議換代的必然性，提出在下一代網(wǎng)絡中用IPv6協(xié)議取代IPv4。IPv6是1992年提出的，主要起因是由于Web的出現(xiàn)導致了IP網(wǎng)的爆炸性發(fā)展，IP網(wǎng)用戶迅速增加，IP地址空前緊張，由于IPv4只用32位二進制數(shù)來表示地址，地址空間很小，IP網(wǎng)將會因地址耗盡而無法繼續(xù)發(fā)展，因而IPv6首先要解決的問題是擴大地址空間，IPv6有許多優(yōu)良的特性，尤其在IP地址量，安全性，服務質(zhì)量，移動性等方面優(yōu)勢明顯。采用IPv6的網(wǎng)絡將比現(xiàn)有的網(wǎng)絡更具擴展性、更安全，更容易為用戶提供質(zhì)量服務?，F(xiàn)在的IPv6協(xié)議是在1995年由思科(Cisco)公司的Steve Deering和諾基亞(Nokia)公司Robert Hinden完成起草并定稿的，即RFC2460。在1998年IETF對RFC2460進行了較大的改進，形成了現(xiàn)有的RFC2460，1998版。IPv6的其他標準也陸續(xù)由IETF的相關工作組制定出來，現(xiàn)已有100多項有關IPv6的RFC制定出來。
我國在互聯(lián)網(wǎng)領域起步較晚，目前所有的合法IPv4地址數(shù)量尚且不如美國一所大學。然而巨大的市場使得我國互聯(lián)網(wǎng)產(chǎn)業(yè)發(fā)展的及其迅速，這就使得國內(nèi)網(wǎng)絡運營商深切地感到IP地址不足產(chǎn)生的嚴重制約作用，可以說現(xiàn)有IPv4地址的資源匱乏已經(jīng)成為中國的互聯(lián)網(wǎng)和通信行業(yè)發(fā)展的瓶頸，IPv6在我國勢在必行。所以，中國是全球最關心下一代互聯(lián)網(wǎng)發(fā)展的國家之一。
IPv6作為下一代網(wǎng)絡的核心技術得到了國家的充分重視。中國在2003年底宣布實施由國家發(fā)改委等八部委聯(lián)合領導的“中國下一代互聯(lián)網(wǎng)示范工程CNGI”新一代互聯(lián)網(wǎng)計劃，按計劃，中國將在2005年底以前投資14億元構筑連接中國各主要城市的IPv6商用骨干網(wǎng)，2006年正式開始IPv6商用服務，屆時將形成全球最大規(guī)模的IPv6商用網(wǎng)。為此，IPv6已經(jīng)列入許多國內(nèi)網(wǎng)絡和通信運營商的網(wǎng)絡規(guī)劃和設備生產(chǎn)商的產(chǎn)品發(fā)展規(guī)劃之中，為IPv6網(wǎng)絡的應用提供了有利的環(huán)境。
然而，雖然在理論上IPv6可以支持很多服務(移動、安全等)，但是與IPv4已經(jīng)成熟的實際應用服務的豐富多彩相比，我國針對IPv6的實際應用和相關技術卻尚處在研發(fā)階段，有些領域還是空白，運營商和設備提供方能夠給用戶提供的服務較之IPv4還有不小差距，這就極大的限制了IPv6網(wǎng)絡在我國的發(fā)展和普及。也必將造成IPv6網(wǎng)絡資源的極大浪費。成為我國下一代互聯(lián)網(wǎng)發(fā)展的障礙。
所以，同時研發(fā)針對IPv6的相關應用技術是推廣我國IPv6的發(fā)展和普及我國IPv6用戶的迫切要求。

發(fā)明內(nèi)容
本發(fā)明是一種建立在IPv6基礎上的相關應用技術，提供了一種IPv6網(wǎng)絡中實現(xiàn)動態(tài)域名更新的方法。解決了在IPv6網(wǎng)絡中動態(tài)域名解析的問題。
本發(fā)明解決其技術問題所采用的技術方案是一種IPv6網(wǎng)絡中實現(xiàn)動態(tài)域名更新的方法，含有3個步驟步驟一DHCPv6服務器與客戶端主機交互分配地址階段；通過DHCPv6客戶端與服務器的交互機制，DHCPv6客戶端向服務器傳遞客戶端主機上由用戶自己定義的客戶端主機名稱，DHCPv6服務器向客戶端傳遞DHCPv6服務器所在域的本地域名；本發(fā)明方案在這一階段中提出了兩種選項類型；步驟二DHCPv6服務器與客戶端主機交互協(xié)商域名階段；含有以下步驟；步驟1，客戶端如果對收到Reply報文中的選項的內(nèi)容表示同意，則將向服務器發(fā)送DNS-UPDATE報文；步驟2，客戶端如果不同意，則向服務器發(fā)送Reply報文，其中的選項內(nèi)容與收到的一致，但是State Code選項中的字段為UnspecFail，此時，更新停止；步驟3，如果服務器收到了DNS-UPDATE報文，則檢查內(nèi)部的記錄，查找是否已經(jīng)有其他客戶端使用此名稱進行了域名的更新；步驟4，如果沒有則向客戶端發(fā)出Reply報文，其內(nèi)容與收到的報文一致，進入步驟6；步驟5，如果發(fā)現(xiàn)已經(jīng)有其他客戶端使用此名稱進行了域名的更新，則向客戶端發(fā)送Reply報文，客戶端可以選擇停止進行域名的動態(tài)更新或者更換主機名稱并重新發(fā)送DNS-UPDATE報文(回到步驟1)；
步驟6，如果雙方協(xié)商成功，則服務器將該客戶端主機IP地址和域名的正向及反向映射記錄下來，寫入磁盤；本發(fā)明方案在這一階段提出了一種DHCPv6協(xié)議報文類型；步驟三DHCPv6服務器與DNS服務器交互階段；含有以下步驟；步驟1，DHCPv6服務器仍然使用DNS-UPDATE報文向DNS服務器進行域名的更新，DNS服務器收到DNS-UPDATE報文后，確定所要更新的區(qū)，DNS服務器將客戶端主機的域名和IP地址的正向和反向映射寫入?yún)^(qū)數(shù)據(jù)文件，成為新的記錄；同時，確定該記錄的生存時間，更新成功后，DNS服務器向DHCPv6服務器發(fā)送Reply報文；步驟2，如果DNS服務器收到DNS-UPDATE報文，發(fā)現(xiàn)在區(qū)數(shù)據(jù)文件中已經(jīng)存在一個相同的客戶端主機名稱的記錄，DNS服務器則向DHCPv6服務器發(fā)送符合DHCPv6協(xié)議的Reply報文，DHCPv6服務器將該Reply報文不變的轉發(fā)給客戶端，此時就回到了步驟二，客戶端可以選擇停止進行域名的動態(tài)更新或者更換主機名稱并重新發(fā)送DNS-UPDATE報文。
本發(fā)明方案在這一階段提出了兩種DHCPv6協(xié)議報文類型；本發(fā)明的有益效果是隨著IPv6網(wǎng)絡的普及和個人用戶需求水平的提高，越來越多的個人用戶已不滿足上網(wǎng)僅僅就是瀏覽網(wǎng)頁和收發(fā)郵件，他們希望擁有自己個性化的域名、建立個人網(wǎng)站、搭建WEB、FTP等個人服務器，從而更好地在因特網(wǎng)中與人交流，更好地利用因特網(wǎng)展示自己，更好地通過因特網(wǎng)遠程獲取資源。但是，在很多網(wǎng)絡中地址分配方案是動態(tài)的，用戶沒有固定的IP地址。這樣，用戶需求就沒法滿足。尤其是在未來的IPv6移動網(wǎng)絡中，這個問題顯得尤為突出。因為那個時候，很多用戶甚至目前運行的很多服務器都將移動起來，IPv6地址的不確定性非常大。而解決這個問題，只有通過在IPv6下的動態(tài)域名更新的方法。
本發(fā)明技術方案解決了IPv6網(wǎng)絡中動態(tài)域名解析的問題。整個過程都由設備自動完成，用戶不須任何人為操作。有利于IPv6技術的推廣與應用。尤其是在未來的移動IPv6網(wǎng)絡中，本發(fā)明技術方案使得移動IPv6用戶的普通PC機在不斷切換的IPv6網(wǎng)絡中成為一臺穩(wěn)定的WEB服務器或者FTP服務器。為移動IPv6用戶帶來巨大的經(jīng)濟效益和社會效益。
本發(fā)明技術方案基于不斷變化的網(wǎng)絡情況，著眼于未來的移動IPv6網(wǎng)絡，面向日益增加的移動IPv6用戶，解決了在IPv6網(wǎng)絡中進行動態(tài)域名解析的問題，極大的方便了用戶，適用于民用和商用的IPv6網(wǎng)絡，并且有望在未來的移動IPv6網(wǎng)絡中得到廣泛的應用。


圖1，流程圖；圖2，現(xiàn)有技術示意圖。
具體實施例方式
實施例1，一種IPv6網(wǎng)絡中實現(xiàn)動態(tài)域名更新的方法以下步驟以下是本發(fā)明方案三個階段工作過程的描述；步驟一DHCPv6服務器與客戶端主機交互分配地址階段；rfc3315規(guī)定，DHCPv6協(xié)議的報文格式為首部4個字節(jié)，分別是1個字節(jié)的報文類型(msg-type)和3個字節(jié)的傳輸標識符(transaction-id)，剩下的部分全部由不同類型的選項(option)字段組成。目前根據(jù)不同的功能已經(jīng)被rfc確定下來的選項(option)字段一共有29個。
本發(fā)明方案在第一階段提出了兩種選項類型
客戶主機名稱選項Client Hostname Option具體格式如下0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+｜option-code | option-len |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| option-data|| Client Hostname(20 bits) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+選項碼(option-code) 客戶主機名稱(OPTION_CLIENT_HOSTNAME)選項長度(option-len)20選項數(shù)據(jù)(option-data) 即客戶端主機上由用戶自己定義的客戶端主機名稱，這里規(guī)定該名稱不得超過20個字母這種選項類型的用途是在本發(fā)明方案的三個階段，DHCPv6客戶端向DHCPv6服務器以及DHCPv6服務器向DNS服務器傳遞客戶端主機上由用戶自己定義的客戶端主機名稱，也就是向DHCPv6服務器傳遞以上所提出的選項格式中option-data字段的內(nèi)容。
本地域名選項Local Domain Name Option，具體格式如下0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| option-code | option-len |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| option-data || Local Domain Name |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+選項碼(option-code)本地域名(OPTION_LOCAL_DOMAIN_NAME)，
選項長度(option-len)本地域名的實際長度，選項數(shù)據(jù)(option-data) 本地域名的內(nèi)容，這種選項類型的用途是在本發(fā)明方案的三個階段，DHCPv6服務器向DHCPv6客戶端以及DNS服務器向DHCPv6服務器傳遞DHCPv6服務器所在域的本地域名，也就是向DHCPv6客戶端傳遞以上所提出的選項格式中option-data字段的內(nèi)容。
步驟二DHCPv6服務器與客戶端主機交互協(xié)商域名階段本發(fā)明方案在這第二階段提出一種DHCPv6協(xié)議報文類型DNS更新報文DNS-UPDATE其報文格式與rfc3315中規(guī)定的以上13種報文類型相同，如下0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| msg-type | transaction-id |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |. options .
. (variable) .
| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+msg-type 報文類型；transaction-id用于報文交換的標識號；options 選項字段，可以攜帶前面提到的rfc中規(guī)定的29種選項和前面本發(fā)明方案提出的新的選項，以完成不同的功能；步驟三DHCPv6服務器與DNS服務器交互階段；本發(fā)明方案在這第三階段提出兩種DHCPv6協(xié)議報文類型
DNS更新延長報文 DNS-UPDATE-RENEW；DNS更新刪除報文 DNS-UPDATE-DELETE；其報文格式與第二階段提出的DNS更新報文一致。
實施例2，以下是本發(fā)明方案三個階段工作過程的詳細描述，第一階段DHCPv6服務器與客戶端主機交互分配地址階段DHCPv6協(xié)議一共定義有13種報文類型。其協(xié)議功能較之DHCPv4有很多擴展，但是DHCPv6協(xié)議分配地址這部分功能的工作原理大致與DHCPv4相同。
第一步，客戶端主機接入網(wǎng)絡后，如果需要一個或者多個IPv6地址，首先會發(fā)送一個Solicit報文給所有的DHCPv6服務器和中繼代理，尋求可用的服務器，此Solicit報文中用Client Identifier選項字段攜帶標識此客戶端主機的DUID。
第二步，所有收到Solicit報文的DHCPv6服務器都會回復一個Advertise報文，此Advertise報文用Server Identifier選項字段攜帶標識此DHCPv6服務器的DUID，而且還用Client Identifier選項字段攜帶標識此客戶端主機的DUID。
第三步，客戶端主機可能會收到多個Advertise報文，并且根據(jù)其中的Client Identifier選項字段中的DUID辨別哪些是發(fā)給自己，從中選擇一個服務器并發(fā)送Request報文請求地址和一些配置信息，此Request報文用ClientIdentifier選項字段攜帶標識此客戶端主機的DUID，而且還用ServerIdentifier選項字段攜帶標識被選中的DHCPv6服務器的DUID。
第四步，被選中的DHCPv6服務器，也就是收到Request報文，并且發(fā)現(xiàn)其中的Server Identifier選項字段中的DUID是自己的DUID的DHCPv6服務器，會發(fā)送一個Reply報文響應并提供地址和請求的配置信息。沒有被選中的服務器在收到以上的Request報文后，不再做出響應。
在正常的情況下，以上四步報文的交互即可完成DHCPv6服務器對客戶端主機的IPv6地址的分配工作。
如果分配的地址生存時間到期而客戶仍然需要這個地址，則客戶端主機需要在生存時間到期之前向分配給自己地址的DHCPv6服務器發(fā)送Renew報文請求延長生存時間和更新其他的配置參數(shù)，DHCPv6服務器會回復一個Reply報文延長該地址的生存時間并更新其他配置參數(shù)。
如果客戶端主機發(fā)出了Renew報文而沒有得到應有的響應(可能是丟包導致)，則客戶主機會向其他所有可用的DHCPv6服務器發(fā)出Rebind報文，來請求延長生存時間和更新其他的配置參數(shù)，Rebind報文中的IA選項(可能有多個)的內(nèi)容包括有目前分配給此IA的所有地址。當DHCPv6服務器(有可能還是以前給客戶端主機分配地址的服務器)接收到含有IA選項的Rebind報文，它會首先鑒定收到的IA選項中的信息是否與它存儲的客戶信息相匹配。如果DHCPv6服務器針對收到的IA選項沒有找到客戶記錄，則服務器認為收到的IA選項中的地址不適合于客戶主機接口所連接的鏈路。這時DHCPv6服務器可以向客戶端主機回復Reply報文，這個Reply報文中含有客戶端主機發(fā)到DHCPv6服務器的IA選項，IA選項中的地址的生存時間被設為零，以明確通知客戶端主機IA選項中的地址已經(jīng)不再有效。在這種情況下，如果服務器沒有回復Reply報文，即它丟棄了Rebind報文。如果服務器發(fā)現(xiàn)某些地址不適合于客戶主機接口所連接的鏈路，則會在Reply報文中將那些地址的生存時間設為零。如果服務器找到了收到的IA選項中的地址，則它會通過Reply報文將新的生存時間和配置參數(shù)告知客戶端主機。以上的過程在這個IA的所有地址的生存時間到期之后就結束了，此時，客戶端主機可以選擇或者重新發(fā)送Solicit報文獲取新的地址，或者使用其他IA中還沒有到期的地址。
如果客戶端在地址生存時間之內(nèi)不再需要分配的IPv6地址，則發(fā)送Release報文通知分配給自己地址的DHCPv6服務器，然后釋放自己的地址，服務器收到Release報文會回復Reply報文向客戶確認已收到。
如果客戶端檢測到有其他的節(jié)點在使用分配給自己的地址時，需要發(fā)送Decline報文通知分配給自己地址的DHCPv6服務器。DHCPv6服務器接收到Decline報文，如果檢測到地址的確已經(jīng)分配給其他的客戶，則會回復Reply報文向客戶確認已收到。
當客戶端移動到一個新的鏈路上時，分配給連接在以前鏈路上的接口的地址前綴可能已經(jīng)不再適合新的鏈路。移動到新的鏈路有以下幾種情況●客戶端主機重新啟動時，●客戶端主機接入到有線鏈路上時，●客戶端主機從休眠狀態(tài)蘇醒時，●客戶端主機使用無線技術，改變接入點時，無論是哪一種情況，當客戶端移動到新的鏈路上時，客戶端主機必須向所有可用的DHCPv6服務器發(fā)出Confirm報文。在發(fā)出的Confirm報文中，包含分配給客戶端主機這個接口的所有IA。對此進行響應的服務器會指出這些地址是否適合于客戶端主機現(xiàn)在所在的鏈路，并通過Reply報文進行響應。當服務器接收到一個Confirm報文，服務器會檢測報文中的地址是否適合于客戶端主機目前所在鏈路。如果所有的地址都通過的檢測，則服務器會向客戶端主機回復一個Reply報文，該報文中的Status Codes選項為Success；如果所有的地址都沒有通過檢測，則服務器會向客戶端主機回復一個Reply報文，該報文中的Status Codes選項為NotOnLink；如果服務器無法進行這項檢測，則服務器不會發(fā)出Reply報文。如果在客戶端主機沒有接收到任何響應，就繼續(xù)使用現(xiàn)有的地址和其他配置參數(shù)。
以上就是DHCPv6協(xié)議主要的工作過程。
rfc3315規(guī)定，DHCPv6協(xié)議的報文格式為首部4個字節(jié)，分別是1個字節(jié)的msg-type和3個字節(jié)的transaction-id，剩下的部分全部由不同類型的選項(option)字段組成。目前已經(jīng)被rfc確定下來的選項(option)字段一共有29個(編號1-30，缺少10)。如下所示// RFC3315OPTION_CLIENTID 客戶端標識符號選項 1OPTION_SERVERID 服務器標識符號選項 2OPTION_IA_NA 非臨時地址標識聯(lián)盟選項 3OPTION_IA_TA 臨時地址標識聯(lián)盟選項4OPTION_IAADDR標識聯(lián)盟地址選項5OPTION_ORO 選項信息請求選項6OPTION_PREFERENCE優(yōu)先級選項 7OPTION_ELAPSED_TIME 共用時選項 8OPTION_RELAY_MSG 回復報文選項9OPTION_AUTH_MSG 認證選項11OPTION_UNICAST 服務器單播選項 12
OPTION_STATUS_CODE 狀態(tài)碼選項 13OPTION_RAPID_COMMIT 快速處理選項14OPTION_USER_CLASS 用戶組選項 15OPTION_VENDOR_CLASS 銷售方組選項16OPTION_VENDOR_OPTS 銷售方信息選項 17OPTION_INTERFACE_ID 接口標識符號選項18OPTION_RECONF_MSG 重新配置報文選項19OPTION_RECONF_ACCEPT接受重新配置報文選項20// RFC3319SIP servers and domainsOPTION_SIP_DOMAINS SIP服務器域名列表選項 21OPTION_SIP_SERVERS SIP服務器地址列表選項 22// RFC3646DNS servers and domainsOPTION_DNS_RESOLVERSDNS服務器地址選項 23OPTION_DOMAIN_LIST 域名查詢列表選項24// RFC3633Prefix optionsOPTION_IA_PD前綴授權標識聯(lián)盟選項25OPTION_IAPREFIX IA_PD前綴選項 26// RFC3898NIS optionsOPTION_NIS_SERVERS NIS服務器地址選項 27OPTION_NISP_SERVERS NIS+服務器地址選項 28OPTION_NIS_DOMAIN_NAME NIS服務器域名選項 29OPTION_NISP_DOMAIN_NAME NIS+服務器域名選項 30
本發(fā)明方案在這第一階段提出了兩種選項類型客戶主機名稱選項Client Hostname Option，本地域名選項Local Domain Name Option，本階段的交互機制和這兩種選項的使用具體描述如下如圖1所示，步驟1，客戶端主機接入網(wǎng)絡后，如果需要一個或者多個IPv6地址，首先會發(fā)送一個Solicit報文給所有的DHCPv6服務器和中繼代理，尋求可用的DHCPv6服務器。
步驟2，所有收到Solicit報文的DHCPv6服務器都會回復一個Advertise報文，此Advertise報文用Server Identifier選項字段攜帶標識此DHCPv6服務器的DUID，而且還用Client Identifier選項字段攜帶標識此客戶端主機的DUID。
步驟3，客戶端從中選擇一個服務器并發(fā)送Request報文請求地址和一些配置信息。此時，本發(fā)明方案提出如果DHCPv6客戶端需要和服務器對域名進行協(xié)商，就要在這個Request報文中加入本發(fā)明方案上面所提出選項類型ClientHostname選項，此選項的內(nèi)容為客戶端主機上由用戶自己定義的客戶端主機名稱(hostnamel)。
步驟4，被選中的DHCPv6服務器，也就是收到攜帶Client Hostname選項的Request報文的DHCPv6服務器，會發(fā)送一個Reply報文響應并提供地址和請求的配置信息，并且在Reply報文中攜帶Local Domain Name選項，此選項的內(nèi)容為客戶端主機所在域的本地域名(bjtu.edu.cn)。
在正常的情況下，以上四種報文的交互和兩種新的選項的傳遞即可完成DHCPv6服務器對客戶端主機的IPv6地址的分配和雙方都得到對方關于域名的信息的工作。
本發(fā)明方案的第一階段到此結束。
第二階段DHCPv6服務器與客戶端主機交互協(xié)商域名階段；此時，地址分配的工作已經(jīng)完成，而且客戶端與服務器都知道了對方的和域名有關的信息，雙方開始協(xié)商域名。
DHCPv6協(xié)議一共有13種報文類型，rfc3315對這13種報文類型進行了編號，并且說明了不同的工作步驟由不同的報文類型承擔，如下所示SOLICIT 懇求報文 1ADVERTISE通告報文 2REQUEST 請求報文 3CONFIRM 確認報文 4RENEW刷新報文 5REBIND 重新綁定報文 6REPLY回復報文 7RELEASE 釋放報文 8DECLINE 拒絕報文 9RECONFIGURE 重新配置報文 10INFORMATION-REQUEST 請求信息報文 11RELAY-FORW 傳遞轉發(fā)報文 12RELAY-REPL 傳遞回復報文 13本發(fā)明方案在這第二階段提出一種DHCPv6協(xié)議報文類型DNS更新報文DNS-UPDATE
步驟5，DHCPv6客戶端如果對收到Reply報文中的Local Domain Name選項的內(nèi)容(即本地域名bjtu.edu.cn)表示同意，則將向服務器發(fā)送DNS-UPDATE報文，該報文將攜帶上面的Client Hostname選項和Local Domain Name選項，而且State Code選項中的status-code字段為Success。DHCPv6客戶端如果不同意(可能是客戶端移動到了外地網(wǎng)絡)，則向服務器發(fā)送Reply報文其中的選項內(nèi)容與收到的一致，但是State Code選項中的status-code字段為UnspecFail。此時，更新停止。
步驟6，如果服務器收到了DNS-UPDATE報文，則檢查內(nèi)部的記錄，查找是否已經(jīng)有其他客戶端使用此名稱(hostnamel)進行了域名的更新。如果沒有則向客戶端發(fā)出Reply報文，其內(nèi)容與收到的DNS-UPDATE報文一致，State Code選項中的status-code字段為Success。表示DHCPv6服務器接受此名稱，并將進入第二階段的操作。如果發(fā)現(xiàn)已經(jīng)有其他客戶端使用此名稱進行了域名的更新，則向客戶端發(fā)送Reply報文，其選項的類型與DNS-UPDATE報文一致，但是ClientHostname選項的內(nèi)容為空，而且State Code選項中的status-code字段為UnspecFail。
步驟7，客戶端收到這種Reply報文后即知道了自己的名稱已有人使用，這時客戶端可以選擇停止進行域名的動態(tài)更新或者更換主機名稱(使用hostname2)并重新發(fā)送DNS-UPDATE報文。
如果雙方協(xié)商成功，則DHCPv6服務器將該客戶端主機IP地址和域名的正向及反向映射記錄下來，寫入磁盤。
當然，以上的交互過程都是在網(wǎng)絡狀況良好，報文可以正常到達目的地址的情況下進行的。
在正常的情況下，以上兩種報文的交互即可完成DHCPv6服務器和客戶端對客戶端域名的協(xié)商工作。
本發(fā)明方案的第二階段到此結束。
第三階段DHCPv6服務器與DNS服務器交互階段此時，在DHCPv6服務器將客戶端主機IP地址和域名的正向及反向映射記錄下來，并且寫入磁盤后，DHCPv6服務器將開始構造對本區(qū)域內(nèi)的權威DNS服務器的更新報文。
本發(fā)明方案在這第三階段提出兩種DHCPv6協(xié)議報文類型DNS更新延長報文 DNS-UPDATE-RENEWDNS更新刪除報文 DNS-UPDATE-DELETE本階段交互過程如下步驟8，DHCPv6服務器仍然使用DNS-UPDATE報文向DNS服務器進行域名的更新。該報文攜帶的選項類型和各個選項的作用如下OPTION_CLIENTID 1OPTION_SERVERID 2OPTION_IA 3OPTION_IAADDR 5OPTION_STATUS_CODE 13OPTION_DNS_RESOLVERS23OPTION_CLIENT_HOSTNAME此選項類型在本發(fā)明方案在第一階段提出OPTION_LOCAL_DOMAIN_NAME此選項類型在本發(fā)明方案在第一階段提出以上選項在報文中的用途如下
OPTION_SERVERID和OPTION_CLIENTID選項是在第一階段中進行了交互的網(wǎng)絡中DHCPv6服務器和客戶端主機的唯一性標識。
OPTION_IA選項向DNS服務器說明了IAID。
OPTION_IAADDR選項攜帶了分配給客戶端主機的IP地址，及其生存時間。
OPTION_STATUS_CODE選項中的status-code字段為Success。
OPTION_DNS_RESOLVERS選項中攜帶了本區(qū)域內(nèi)的DNS服務器的IP地址。
OPTION_CLIENT_HOSTNAME選項中為客戶端主機名稱(hostnamel)。
OPTION_LOCAL_DOMAIN_NAME選項指出了客戶端主機所在的域的本地域名(例如bjtu.edu.cn)。
步驟9，DNS服務器收到DNS-UPDATE報文后，首先根據(jù)OPTION_LOCAL_DOMAIN_NAME選項確定所要更新的區(qū)(bjtu.edu.cn)，這里注意一個DNS服務器上可能有多個區(qū)的記錄，如果找到OPTION_LOCAL_DOMAIN_NAME選項中所指的區(qū)，DNS服務器根據(jù)OPTION_LOCAL_DOMAIN_NAME選項、OPTION_CLIENT_HOSTNAME選項、OPTION_IAADDR選項將客戶端主機的域名(hostnamel.bjtu.edu.cn)和IP地址的正向和反向映射寫入?yún)^(qū)數(shù)據(jù)文件，成為新的記錄。同時，根據(jù)OPTION_IAADDR選項中客戶端主機的IP地址的生存時間確定該記錄的生存時間，生存時間到期后DNS服務器將刪除該記錄。更新成功后，DNS服務器向DHCPv6服務器發(fā)送Reply報文，其中的選項字段與其收到的DNS-UPDATE報文完全一樣，這樣，DHCPv6服務器就知道了DNS服務器已經(jīng)收到了DNS-UPDATE報文，并且新的記錄已經(jīng)添加成功。
如果DNS服務器收到DNS-UPDATE報文，發(fā)現(xiàn)在區(qū)數(shù)據(jù)文件中已經(jīng)存在一個相同的客戶端主機名稱的記錄(hostnamel.bjtu.edu.cn到某個IPv6地址的正向和反向映射)，這種情況屬于不同的用戶給自己的客戶端主機起了相同的名字，并且通過其他的DHCPv6服務器對DNS服務器進行了更新(DHCPv6服務器可能有多個)，注意這時相同名稱的客戶端的IP地址是不同的，而且其生存時間可能不同。這時，DNS服務器則向DHCPv6服務器發(fā)送符合DHCPv6協(xié)議的Reply報文，其選項的類型與DNS-UPDATE報文一致，但是Client Hostname選項的內(nèi)容為空，而且State Code選項中的status-code字段為UnspecFail。
步驟10，DHCPv6服務器收到這種Reply報文后即知道了該域名已有人使用，這時DHCPv6服務器將該Reply報文不變的轉發(fā)給客戶端。
步驟11，客戶端此時可以選擇停止進行域名的動態(tài)更新或者更換主機名稱并重新發(fā)送DNS-UPDATE報文，此時就回到了第二階段的步驟5。
步驟12，如果分配的地址生存時間到期而客戶仍然需要這個地址，則客戶端主機需要在生存時間到期之前向分配給自己地址的DHCPv6服務器發(fā)送Renew報文請求延長生存時間和更新其他的配置參數(shù)。
步驟13，DHCPv6服務器回復一個Reply報文延長該地址的生存時間并更新其他配置參數(shù)。
步驟14，這時，DHCPv6服務器向剛才的DNS服務器發(fā)出DNS-UPDATE-RENEW報文，其中的選項字段與上面的DNS-UPDATE報文完全一樣，只是地址的生存時間會有所不同。
步驟15，DNS服務器收到DNS-UPDATE-RENEW報文后，查找到區(qū)中已經(jīng)存在相同的記錄，而且通過OPTION_SERVERID和OPTION_CLIENTID選項知道是相同的DHCPv6服務器發(fā)出的相同客戶端主機的域名和地址的映射的DNS-UPDATE-RENEW報文后，則DNS服務器將在當時的時刻相應的延長這條記錄的生存時間。成功后，DNS服務器向DHCPv6服務器發(fā)送Reply報文，其中的選項字段與其收到的DNS-UPDATE-RENEW報文完全一樣，只是OPTION_IAADDR選項中地址的生存時間為總時間。這樣，DHCPv6服務器就知道了DNS服務器已經(jīng)收到了用來延長記錄生存時間的DNS-UPDATE-RENEW報文，并且記錄生存時間延長成功。
如果DNS服務器收到DNS-UPDATE-RENEW報文后，但是沒有查詢到相應的區(qū)，或者在區(qū)中沒有查到相應的原始記錄，將丟棄DNS-UPDATE-RENEW報文。
步驟16，如果客戶端主機在地址生存時間之內(nèi)不再需要分配的IPv6地址，則發(fā)送Release報文通知分配給自己地址的DHCPv6服務器，然后釋放自己的地址。
步驟17，服務器收到Release報文會回復Reply報文向客戶確認已收到。
步驟18，這時，DHCPv6服務器會向DNS服務器發(fā)出DNS-UPDATE-DELETE報文，其中的選項字段與上面的DNS-UPDATE報文完全一樣。
步驟19，DNS服務器收到DNS-UPDATE-DELETE報文，查到相應的記錄加以刪除。并且發(fā)送Reply報文加以確認。
如果DNS服務器收到DNS-UPDATE-DELETE報文后，但是沒有查詢到相應的區(qū)，或者在區(qū)中沒有查到相應的原始記錄，將丟棄DNS-UPDATE-DELETE報文。
本發(fā)明方案的第三階段到此結束。
以上就是本發(fā)明方案的三個階段全部過程的所有操作。根據(jù)這些操作最終實現(xiàn)了在DNS服務器上客戶端主機域名的動態(tài)添加和刪除。實現(xiàn)了IPv6網(wǎng)絡中動態(tài)域名解析功能。
權利要求
1.一種IPv6網(wǎng)絡中實現(xiàn)動態(tài)域名更新的方法，其特征是含有3個步驟；步驟一DHCPv6服務器與客戶端主機交互分配地址階段；通過DHCPv6客戶端與服務器的交互機制，DHCPv6客戶端向服務器傳遞客戶端主機上由用戶自己定義的客戶端主機名稱，DHCPv6服務器向客戶端傳遞DHCPv6服務器所在域的本地域名；步驟二DHCPv6服務器與客戶端主機交互協(xié)商域名階段；含有以下步驟；步驟1，客戶端如果對收到Reply報文中的選項的內(nèi)容表示同意，則將向服務器發(fā)送DNS-UPDATE報文，步驟2，客戶端如果不同意，則向服務器發(fā)送Reply報文其中的選項內(nèi)容與收到的一致，但是State Code選項中的字段為UnspecFail，此時，更新停止；步驟3，如果服務器收到了DNS-UPDATE報文，則檢查內(nèi)部的記錄，查找是否已經(jīng)有其他客戶端使用此名稱進行了域名的更新；步驟4，如果沒有則向客戶端發(fā)出Reply報文，其內(nèi)容與收到的報文一致，進入步驟6；步驟5，如果發(fā)現(xiàn)已經(jīng)有其他客戶端使用此名稱進行了域名的更新，則向客戶端發(fā)送Reply報文，客戶端可以選擇停止進行域名的動態(tài)更新或者更換主機名稱并重新發(fā)送DNS-UPDATE報文；步驟6，如果雙方協(xié)商成功，則服務器將該客戶端主機IP地址和域名的正向及反向映射記錄下來，寫入磁盤；步驟三DHCPv6服務器與DNS服務器交互階段；含有以下步驟；步驟1，DHCPv6服務器仍然使用DNS-UPDATE報文向DNS服務器進行域名的更新，DNS服務器收到DNS-UPDATE報文后，確定所要更新的區(qū)，DNS服務器將客戶端主機的域名和IP地址的正向和反向映射寫入?yún)^(qū)數(shù)據(jù)文件，成為新的記錄；同時，確定該記錄的生存時間，更新成功后，DNS服務器向DHCPv6服務器發(fā)送Reply報文；步驟2，如果DNS服務器收到DNS-UPDATE報文，發(fā)現(xiàn)在區(qū)數(shù)據(jù)文件中已經(jīng)存在一個相同的客戶端主機名稱的記錄，DNS服務器則向DHCPv6服務器發(fā)送符合DHCPv6協(xié)議的Reply報文，DHCPv6服務器將該Reply報文不變的轉發(fā)給客戶端，此時就回到了步驟二，客戶端可以選擇停止進行域名的動態(tài)更新或者更換主機名稱并重新發(fā)送DNS-UPDATE報文。
2.根據(jù)權利要求1所述的一種IPv6網(wǎng)絡中實現(xiàn)動態(tài)域名更新的方法，其特征是第一階段報文類型有兩種選項類型客戶主機名稱選項有選項碼、客戶主機名稱、選項長度、選項數(shù)據(jù)；本地域名選項有選項碼、本地域名、選項長度、本地域名的實際長度、選項數(shù)據(jù)；第二階段協(xié)議報文類型DNS更新報文，有報文類型、用于報文交換的標識號、選項字段；第三階段有兩種DHCPv6協(xié)議報文類型，DNS更新延長報文和DNS更新刪除報文，其報文格式與第二階段提出的DNS更新報文一致。
3.根據(jù)權利要求1或2所述的一種IPv6網(wǎng)絡中實現(xiàn)動態(tài)域名更新的方法，其特征是如果客戶端主機在生存時間到期之前向分配給自己地址的DHCPv6服務器發(fā)送Renew報文請求延長生存時間和更新其他的配置參數(shù)，并且DHCPv6服務器回復了Reply報文延長該地址的生存時間并更新其他配置參數(shù)，這時，DHCPv6服務器向剛才的DNS服務器發(fā)出DNS-UPDATE-RENEW報文，DNS服務器收到DNS-UPDATE-RENEW報文后，查找到區(qū)中已經(jīng)存在相同的記錄，則DNS服務器將在當時的時刻相應的延長這條記錄的生存時間，成功后，DNS服務器向DHCPv6服務器發(fā)送Reply報文；如果DNS服務器收到DNS-UPDATE-RENEW報文后，但是沒有查詢到相應的區(qū)，或者在區(qū)中沒有查到相應的原始記錄，將丟棄DNS-UPDATE-RENEW報文；如果客戶端主機不再需要分配的IPv6地址，則發(fā)送Release報文通知分配給自己地址的DHCPv6服務器，服務器收到Release報文會回復Reply報文向客戶確認已收到；這時，DHCPv6服務器會向DNS服務器發(fā)出DNS-UPDATE-DELETE報文，DNS服務器收到DNS-UPDATE-DELETE報文，查到相應的記錄加以刪除；并且發(fā)送Reply報文加以確認；如果DNS服務器收到DNS-UPDATE-DELETE報文后，但是沒有查詢到相應的區(qū)，或者在區(qū)中沒有查到相應的原始記錄，將丟棄DNS-UPDATE-DELETE報文。
全文摘要
一種IPv6網(wǎng)絡中實現(xiàn)動態(tài)域名更新的方法。含有3個步驟；步驟一DHCPv6服務器與客戶端主機交互分配地址階段；步驟二DHCPv6服務器與客戶端主機交互協(xié)商域名階段；步驟三DHCPv6服務器與DNS服務器交互階段；本發(fā)明技術方案使得移動IPv6用戶的普通PC機在不斷切換的IPv6網(wǎng)絡中隨時隨地的成為一臺穩(wěn)定的WEB服務器或者FTP服務器?；诓粩嘧兓木W(wǎng)絡情況，著眼于未來的移動IPv6網(wǎng)絡，面向日益增加的移動IP用戶，解決了在IPv6網(wǎng)絡中進行動態(tài)域名解析的問題，極大的方便了用戶，適用于民用和商用的IPv6網(wǎng)絡，并且有望在未來的移動IPv6網(wǎng)絡中得到廣泛的應用。
文檔編號H04L29/12GK1694459SQ20051001156
公開日2005年11月9日 申請日期2005年4月13日 優(yōu)先權日2005年4月13日
發(fā)明者張宏科, 沈劍, 郜帥, 秦雅娟 申請人:北京交通大學