伴隨著IPv6的部署發(fā)展，越來越多公司和機構(gòu)開始使用IPv6作為主要接入線路了，這就帶來了一個比較麻煩的麻煩的沖突問題，舊的網(wǎng)絡(luò)協(xié)議和新的網(wǎng)絡(luò)協(xié)議難免會存在沖突的情況，尤其是IPv6遷移給DNS處理帶來麻煩，下面就這個問題分析一下。

一、目前采用的雙雙協(xié)議棧模式，這與隧道和轉(zhuǎn)換模式相比，它屬于最可行的應用模式。

原因就在于部署起來最簡單，并且可以為終端設(shè)備提供最廣泛的兼容性，作為一項系統(tǒng)工程，讓現(xiàn)實世界中的所有設(shè)備都從當前的互聯(lián)網(wǎng)標準全部遷移到IPV6的工作需要耗費相當長的時間，想要實現(xiàn)從IPv4協(xié)議遷移到IPv6協(xié)議上的大規(guī)模操作。這一過程的進度將會非常緩慢，并且將需要耗費掉幾年的時間。在此期間，所有用戶都必須面臨著需要通過某種方式同時支持兩種協(xié)議運行的情況。

二、還就是在目前比較流行的云計算方面，在很大程度上也需要依靠IP地址來對數(shù)量眾多的計算、存儲和網(wǎng)絡(luò)資源進行整合和連接，他們還需要為客戶提供DNS之類的公共服務。

因此，他們建立了一套基于腳本和管理框架的復雜系統(tǒng)來對提供服務所必須的自動化和遠程控制項目進行監(jiān)管，對于云服務供應商來說，不僅需要保證外部服務可以同時支持兩種版本，而且需要確保內(nèi)部系統(tǒng)、框架和控制功能也必須兼容了這一要求。

三、對于云計算供應商，尤其是采用軟件即服務模式的公司來說，相比基礎(chǔ)設(shè)施即服務類同行，開展工作的難度可能不會那么高。

原因就在于基礎(chǔ)設(shè)施即服務類供應商需要同時處理客戶配置和自身虛擬鏡像控制兩方面的問題，在這種情況下，很多問題可能依賴于IPv4協(xié)議而不是IPv6協(xié)議，反之亦然。

四、而對于應用或者其它類型的服務來說，在開發(fā)時往往會利用IP地址來識別所有來自外部或者第三方的集成服務。并且，通常情況下，這些應用是由最終用戶而不是供應商控制的，這并不意味著軟件即服務類供應商就可以高枕無憂了。

所有部署到云計算環(huán)境中的應用都需要集成到企業(yè)數(shù)據(jù)中心里，反過來也一樣，這就等于存在使用不同IP版本來提供安全或者集成功能的情況，它可能會導致不兼容情況，或者讓遷移過程無法徹底完成。

五、由于規(guī)模如此巨大的遷移需要涉及到無數(shù)項不同變量，這就意味著我們將面臨數(shù)不盡的挑戰(zhàn);因此，它絕對不會是一項扳動下開關(guān)就可以全部完成的簡單工作。

所以，在決定進行遷移之前，相關(guān)各方必須進行全面合作和精心策劃，確保在不會出現(xiàn)大規(guī)模停機的情況下，可以將具體工作逐步開展下去。

六、由于大部分基礎(chǔ)設(shè)備中都已經(jīng)包含了雙協(xié)議棧，所以，相關(guān)需求可以得到充分滿足。但是，即便運行了雙協(xié)議棧，也不等于已經(jīng)可以將以網(wǎng)絡(luò)和應用為導向的眾多服務都整合連接到了一起，從網(wǎng)站連接的實際過程來看，這項工作比看起來復雜得多。

DNS服務器需要可以被查詢，數(shù)據(jù)包需要能夠通過路由進行傳遞，TCP會話需要容許被發(fā)起，數(shù)據(jù)包需要時刻進行交換。

七、對于網(wǎng)站所在的數(shù)據(jù)中心來說，即便是響應ICMP echo請求查詢這樣的最簡單工作，也需要包括軟件和硬件在內(nèi)的眾多組件進行互動協(xié)作才能完成，由于雙協(xié)議棧不一定能夠被兼容IPv6協(xié)議的服務包括在內(nèi)。

大家可以想象一下，在這種情況下，如果一臺IPv4終端查詢網(wǎng)站IP地址時， DNS服務器必須作出回應，對于DNS服務器來說，怎樣才能確認使用協(xié)議的正確版本以便響應呢?

當我們從當前版本遷移到新版本的時間，應用環(huán)境需要同時支持兩種版本，這就意味著互聯(lián)網(wǎng)基礎(chǔ)服務設(shè)施也必須做到這一點，這讓實際工作比最初看起來的情況復雜得多。