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

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


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