監(jiān)理公司管理系統(tǒng) | 工程企業(yè)管理系統(tǒng) | OA系統(tǒng) | ERP系統(tǒng) | 造價(jià)咨詢(xún)管理系統(tǒng) | 工程設(shè)計(jì)管理系統(tǒng) | 簽約案例 | 購(gòu)買(mǎi)價(jià)格 | 在線(xiàn)試用 | 手機(jī)APP | 產(chǎn)品資料
X 關(guān)閉

如何實(shí)現(xiàn)IPv4到IPv6的遷移？

申請(qǐng)免費(fèi)試用、咨詢(xún)電話(huà)：400-8352-114

全球范圍的IPv4地址已經(jīng)被全球IPv4地址分配管理組織IANA于今年分配完畢,新一代互聯(lián)網(wǎng)協(xié)議IPv6于6月6日正式上線(xiàn)，全球各大網(wǎng)站和網(wǎng)絡(luò)服務(wù)提供商(ISP)將進(jìn)行為期24小時(shí)的IPv6測(cè)試。升級(jí)之前，全世界人均能夠分配到的IP地址不到一個(gè)，升級(jí)之后這一數(shù)字飆升到了10億。
 
但由于IPv6協(xié)議設(shè)計(jì)缺陷，導(dǎo)致它不能與IPv4兼容，使得目前階段，根本無(wú)法實(shí)現(xiàn)向IPv6網(wǎng)整體遷移。那么如何實(shí)現(xiàn)IPv4到IPv6的遷移呢？
 
IETF提出了三種IPv4到IPv6的遷移過(guò)渡機(jī)制，即雙棧、隧道和地址翻譯。其中雙棧和隧道機(jī)制僅在網(wǎng)絡(luò)層面解決IPv4網(wǎng)絡(luò)與IPv6網(wǎng)絡(luò)的共存問(wèn)題，地址翻譯機(jī)制在業(yè)務(wù)層面解決異構(gòu)網(wǎng)絡(luò)業(yè)務(wù)之間的互通問(wèn)題。具體說(shuō)來(lái)，IPv4到IPv6的遷移技術(shù)有以下幾種：
 
1.雙協(xié)議棧技術(shù)
 
IPv6和IPv4是功能相近的網(wǎng)絡(luò)層協(xié)議，兩者都基于相同的物理平臺(tái)，而且加載于其上的傳輸層協(xié)議TCP和UDP又沒(méi)有任何區(qū)別。由圖1所示的協(xié)議棧結(jié)構(gòu)可以看出，如果一臺(tái)主機(jī)同時(shí)支持IPv6和IPv4兩種協(xié)議，那么該主機(jī)既能與支持IPv4協(xié)議的主機(jī)通信，又能與支持IPv6協(xié)議的主機(jī)通信，這就是雙協(xié)議棧技術(shù)的工作機(jī)理。
 
2.隧道技術(shù)
 
隨著IPv6網(wǎng)絡(luò)的發(fā)展，出現(xiàn)了許多局部的IPv6網(wǎng)絡(luò)，但是這些IPv6網(wǎng)絡(luò)需要通過(guò)IPv4骨干網(wǎng)絡(luò)相連。將這些孤立的"IPv6島"相互聯(lián)通必須使用隧道技術(shù)。利用隧道技術(shù)可以通過(guò)現(xiàn)有的運(yùn)行IPv4協(xié)議的Internet骨干網(wǎng)絡(luò)（即隧道）將局部的IPv6網(wǎng)絡(luò)連接起來(lái)，因而是IPv4向IPv6過(guò)渡的初期最易于采用的技術(shù)。
 
路由器將IPv6的數(shù)據(jù)分組封裝入IPv4，IPv4分組的源地址和目的地址分別是隧道入口和出口的IPv4地址。在隧道的出口處，再將IPv6分組取出轉(zhuǎn)發(fā)給目的站點(diǎn)。隧道技術(shù)只要求在隧道的入口和出口處進(jìn)行修改，對(duì)其他部分沒(méi)有要求，因而非常容易實(shí)現(xiàn)。但是隧道技術(shù)不能實(shí)現(xiàn)IPv4主機(jī)與IPv6主機(jī)的直接通信。
 
3.網(wǎng)絡(luò)地址轉(zhuǎn)換/協(xié)議轉(zhuǎn)換技術(shù)
 
網(wǎng)絡(luò)地址轉(zhuǎn)換/協(xié)議轉(zhuǎn)換技術(shù)NAT-PT (NetworkAddressTranslation-ProtocolTranslation)通過(guò)與SIIT協(xié)議轉(zhuǎn)換和傳統(tǒng)的IPv4下的動(dòng)態(tài)地址翻譯（NAT）以及適當(dāng)?shù)膽?yīng)用層網(wǎng)關(guān)（ALG）相結(jié)合，實(shí)現(xiàn)了只安裝了IPv6的主機(jī)和只安裝了IPv4機(jī)器的大部分應(yīng)用的相互通信。
 
4.SOCKS64
 
一個(gè)是在客戶(hù)端里引入SOCKS庫(kù)，這個(gè)過(guò)程稱(chēng)為"socks化"（socksifying），它處在應(yīng)用層和socket之間，對(duì)應(yīng)用層的socket API和DNS名字解析API進(jìn)行替換；
 
另一個(gè)是SOCKS網(wǎng)關(guān)，它安裝在IPv6/v4雙棧結(jié)點(diǎn)上，是一個(gè)增強(qiáng)型的SOCKS服務(wù) 器，能實(shí)現(xiàn)客戶(hù)端C和目的端D之間任何協(xié)議組合的中繼。當(dāng)C上的SOCKS庫(kù)發(fā)起一個(gè)請(qǐng)求后，由網(wǎng)關(guān)產(chǎn)生一個(gè)相應(yīng)的線(xiàn)程負(fù)責(zé)對(duì)連接進(jìn)行中繼。SOCKS庫(kù) 與網(wǎng)關(guān)之間通過(guò)SOCKS（SOCKSv5）協(xié)議通信，因此它們之間的連接是"SOCKS化"的連接，不僅包括業(yè)務(wù)數(shù)據(jù)也包括控制信息；而G和D之間的連 接未作改動(dòng)，屬于正常連接。D上的應(yīng)用程序并不知道C的存在，它認(rèn)為通信對(duì)端是G。
 
5.傳輸層中繼（Transport Relay）
 
與SOCKS64的工作機(jī)理相似，只不過(guò)是在傳輸層中繼器進(jìn)行傳輸層的"協(xié)議翻譯"，而 SOCKS64是在網(wǎng)絡(luò)層進(jìn)行協(xié)議翻譯。它相對(duì)于SOCKS64，可以避免"IP分組分片"和"ICMP報(bào)文轉(zhuǎn)換"帶來(lái)的問(wèn)題，因?yàn)槊總€(gè)連接都是真正的 IPV4或IPV6連接。但同樣無(wú)法解決網(wǎng)絡(luò)應(yīng)用程序數(shù)據(jù)中含有網(wǎng)絡(luò)地址信息所帶來(lái)的地址無(wú)法轉(zhuǎn)換的問(wèn)題。
 
6.應(yīng)用層代理網(wǎng)關(guān)（ALG）
 
ALG是Application Level Gateway的簡(jiǎn)稱(chēng)，與SOCKS64、傳輸層中繼等技術(shù)一樣，都是在V4與V6間提供一個(gè)雙棧網(wǎng)關(guān)，提供"協(xié)議翻譯"的功能，只不過(guò)ALG是在應(yīng)用層 級(jí)進(jìn)行協(xié)議翻譯。這樣可以有效解決應(yīng)用程序中帶有網(wǎng)絡(luò)地址的問(wèn)題，但ALG必須針對(duì)每個(gè)業(yè)務(wù)編寫(xiě)單獨(dú)的ALG代理，同時(shí)還需要客戶(hù)端應(yīng)用也在不同程序上支 持ALG代理，靈活性很差。顯然，此技術(shù)必須與其它過(guò)渡技術(shù)綜合使用，才有推廣意義。
 
無(wú)論采用哪種IPv4到IPv6的遷移技術(shù)，有一點(diǎn)可以肯定：這些遷移技術(shù)只是臨時(shí)的替代方案，未來(lái)IPv4終將被IPv6淘汰，至于如何選擇，則要看自身業(yè)務(wù)發(fā)展和自身所具備的硬件條件。

【推薦閱讀】

◆數(shù)據(jù)庫(kù)遷移我們?cè)撟⒁饽男┦马?xiàng)？

◆詳解云計(jì)算服務(wù)遷移注意事項(xiàng)

◆服務(wù)器安全維護(hù)的七大方案

◆IT運(yùn)維管理專(zhuān)區(qū)

◆網(wǎng)管軟件專(zhuān)區(qū)

本文來(lái)自互聯(lián)網(wǎng)，僅供參考
發(fā)布：2007-04-15 10:39    編輯：泛普軟件 · xiaona    [打印此頁(yè)]    [關(guān)閉]
相關(guān)文章：

泛普重慶OA快博其他應(yīng)用

重慶OA軟件 重慶OA新聞動(dòng)態(tài) 重慶OA信息化 重慶OA客戶(hù) 重慶OA快博 重慶OA行業(yè)資訊 重慶軟件開(kāi)發(fā)公司 重慶網(wǎng)站建設(shè)公司 重慶物業(yè)管理軟件 重慶餐飲管理軟件 重慶倉(cāng)庫(kù)管理系統(tǒng) 重慶門(mén)禁系統(tǒng) 重慶微信營(yíng)銷(xiāo) 重慶ERP 重慶監(jiān)控公司 重慶金融行業(yè)軟件 重慶B2B、B2C商城系統(tǒng)開(kāi)發(fā) 重慶建筑施工項(xiàng)目管理系統(tǒng)開(kāi)發(fā)