如果早期互聯(lián)網(wǎng)和TCP/IP網(wǎng)絡(luò)設(shè)計者們讓IPV6兼容IPv4的話，事情將變得非常簡單。但是，很可惜的是他們沒有選擇這么做。對于1981年的阿帕網(wǎng)/互聯(lián)網(wǎng)來說，IPv4提供的43億個32位地址已經(jīng)完全可以滿足需要了。對于互聯(lián)網(wǎng)來說，那真是此一時，彼一時。

　　哦，現(xiàn)在網(wǎng)絡(luò)專家們都意識到互聯(lián)網(wǎng)地址短缺時代的到來，知道這將成為一個問題。我不知道應(yīng)該怎么*價下面的內(nèi)容，在2009年6月的會議上，互聯(lián)網(wǎng)協(xié)會首席互聯(lián)網(wǎng)技術(shù)官萊斯利·代格爾承認，“IPV6缺乏對IPv4的兼容性是非常嚴重的問題”?，F(xiàn)在哭訴標準出現(xiàn)了問題已經(jīng)太晚了。我們現(xiàn)在要做的，是讓這兩個基礎(chǔ)網(wǎng)絡(luò)協(xié)議共同工作。

　　對于這一問題，目前存在幾種處理方式。但我要先提醒你，它們都不是完美的，不過至少有一種或者幾種，可以為公司提供幫助。在購買其中的任何技術(shù)之前，必須對IPV6到IPv4的轉(zhuǎn)換過程進行全面測試，在部署之前，還要對組件的互操作性進行檢驗。這里出現(xiàn)問題的可能性太高了，沒有人會希望它在業(yè)務(wù)網(wǎng)絡(luò)工作時間中出現(xiàn)的。

　　IPv4/IPV6共存模式可以采取下面的三種形式之一...第一種就是雙協(xié)議棧，通過在網(wǎng)絡(luò)硬件上同時運行IPv4和IPV6協(xié)議來實現(xiàn)。第二種就是利用“隧道”方式，利用一種協(xié)議穿過另一種。通常情況下，這意味著將IPV6數(shù)據(jù)包封裝為IPv4數(shù)據(jù)包。這一技術(shù)的說明在RFC　4213標準《IPV6主機和路由的基本轉(zhuǎn)換機制》有詳細介紹。最后，就是依據(jù)RFC　2766標準提供的網(wǎng)絡(luò)地址轉(zhuǎn)換協(xié)議轉(zhuǎn)換器(NAT-PT)。它的工作原理正如名稱中說明的，將IPV6數(shù)據(jù)包轉(zhuǎn)換為IPv4數(shù)據(jù)包的軟件或者設(shè)備。

　　盡管乍看上去，網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)會更受到支持者的喜愛，但這里面也存在固有的問題。正如思科在《網(wǎng)絡(luò)地址轉(zhuǎn)換協(xié)議轉(zhuǎn)換器》優(yōu)先白皮書中指出的，“由于該協(xié)議不屬于普遍適用的通用機制，因此，在特定區(qū)域中進行應(yīng)用部署的時間，必須對所有涉及部分進行全面徹底的分析”。簡單地說，就是如果計劃部署NAT-PT的話，就必須了解周圍應(yīng)用層網(wǎng)關(guān)(ALG)的部署情況。

　　此外，NAT-PT與IPv4下的NAT模式相比，一個關(guān)鍵區(qū)別就是在流量輸入和輸出的時間都必須進行地址轉(zhuǎn)換。這將導致復雜程度飛速上升。盡管可以選擇使用靜態(tài)雙向映射，但它將很快過時也不能支持大規(guī)模的應(yīng)用。當然，還可以使用域名系統(tǒng)(DNS)，但對于舊式DNS服務(wù)器來說，它們將無法支持IPV6的AAAA記錄。并我再重復一次，我不認為在實際中遇到地址請求攻擊時，那些支持IPV6的DNS服務(wù)器不會出現(xiàn)問題。

　　在雙IP堆棧模式下，所有計算機、路由器、交換機和其他設(shè)備都同時運行兩種協(xié)議，而IPV6將是首選協(xié)議。通常情況下，部署過程是從廣域網(wǎng)(WAN)核心路由器的TCP/IP協(xié)議棧開始，接下來擴展到邊界路由器和防火墻，然后輪到數(shù)據(jù)中心路由器，最后到達連接桌面的路由器。由于公共互聯(lián)網(wǎng)已經(jīng)開始過渡到IPV6協(xié)議，網(wǎng)絡(luò)管理員可能需要開始準備在網(wǎng)絡(luò)邊界上部署雙棧交換機了。

　　這種模式的優(yōu)點是，操作系統(tǒng)和網(wǎng)絡(luò)設(shè)備領(lǐng)域所有的主要供應(yīng)商都支持雙IP棧。缺點是，大多數(shù)傳統(tǒng)網(wǎng)絡(luò)硬件和服務(wù)器不支持IPV6。這可能導致用戶試圖訪問互聯(lián)網(wǎng)網(wǎng)站時，雙疊邊緣交換機在*器(DNS)方面出現(xiàn)無法預計的問題。此外，很多版本的互聯(lián)網(wǎng)應(yīng)用，甚至包括文件傳輸協(xié)議(FTP)這么流行的東西，都不能在IPV6下工作。

　　解決這些問題的一種方法是利用雙協(xié)議棧應(yīng)用層網(wǎng)關(guān)(DS-ALG)。通常情況，這些網(wǎng)關(guān)可以作為在IPv4互聯(lián)網(wǎng)中兩種協(xié)議的轉(zhuǎn)換代理。

　　這種方法的缺點是只能針對特定應(yīng)用。并且由于所有數(shù)據(jù)包都會被攔截下來進行檢查以確認是否需要DS-ALG服務(wù)，所以，網(wǎng)絡(luò)速度也會受到影響。

　　而在隧道模式下，一種協(xié)議可以在另一種內(nèi)部運行。通常情況下，是IPV6在IPv4的內(nèi)部。這些隧道可以通過以IPv4為主的內(nèi)部廣域網(wǎng)和互聯(lián)網(wǎng)傳輸IPV6數(shù)據(jù)包。而等到IPV6成為互聯(lián)網(wǎng)的主要協(xié)議時，我們將用IPV6隧道傳輸IPv4流量。

　　目前有兩種類型的隧道：手動又叫做靜態(tài)，以及動態(tài)。手動配置的IPV6隧道，需要在隧道兩端都進行配置。手動模式的適用范圍是用來連接互聯(lián)網(wǎng)上運行IPV6的企業(yè)內(nèi)部網(wǎng)。對于其它類型的IPV6互聯(lián)網(wǎng)來說，它不是一個合適的解決方案。

　　動態(tài)隧道使用了多種技術(shù)來確認數(shù)據(jù)包的到達地址和路由的途徑。這使得它們更容易建立和維護。

　　最常見的動態(tài)隧道技術(shù)是*。它不需要建立一條直接的隧道。與此相反，它可以利用專用中繼路由器來對IPV6數(shù)據(jù)包進行封裝并通過IPv4連接轉(zhuǎn)發(fā)。*的最大優(yōu)點是可以自動建立IPV6/V4隧道，而不必耗費大量時間進行手動設(shè)置。*通過骨干傳輸點利用IPv4單播來建立點對點的連接進行傳輸。

　　為了保證使用中不出現(xiàn)問題，供應(yīng)商和網(wǎng)絡(luò)工程師必須確保安全配置經(jīng)過了精心設(shè)定。畢竟，對于可以利用IPv4和IPV6報頭隱藏錯誤地址以及將惡意流量放進封裝的數(shù)據(jù)包內(nèi)發(fā)動拒絕服務(wù)(DoS)攻擊的黑客來說，這一切都顯得太簡單了。

　　上面提到的就是一些最流行的IPV6和IPv4協(xié)作工具。當然，市面上還有很多其它類型的。想知道對于所有這些工具來說，最糟糕的問題是什么么?答案很簡單，它們的兼容性都很差。正如我在前面所說的，不論是否喜歡，所有人都需要準備遷移到IPV6上。

　　與此同時，在未來幾年里，我們幾乎肯定需要這些技術(shù)中的一種或者幾種。同樣，在部署任何IPv4/IPV6橋接解決方案之前，我們需要花費大量時間讓網(wǎng)絡(luò)工程師和供應(yīng)商進行調(diào)試以確保在新的網(wǎng)絡(luò)堆棧一切都可以互操作。畢竟，混合模式和設(shè)備導致網(wǎng)絡(luò)出現(xiàn)問題是件一點也不困難的事情。

　　我還要補充一點，在選擇確定軟件和硬件之前一定要進行測試。我已經(jīng)遇見了多起這樣的情況，盡管宣稱可以支持IPV6，但實際測試結(jié)果正好相反。對于這種情況，改天我會向大家詳細介紹。