雙?；A(chǔ)上的下一代互聯(lián)網(wǎng)過(guò)渡技術(shù)及策略

趙慧玲，陳運(yùn)清，孫 瓊，王 茜

（中國(guó)電信股份有限公司北京研究院 北京 100035）

1 概述

目前，IPv4地址已經(jīng)呈現(xiàn)越來(lái)越緊缺的態(tài)勢(shì)，分配機(jī)構(gòu)（IANA）根據(jù)最近3年的地址使用數(shù)據(jù)，預(yù)測(cè)全球IPv4地址資源將于2011年底前后耗盡。在我國(guó)，IPv4地址短缺問(wèn)題尤為嚴(yán)重。在這種情況下，IPv6作為下一代互聯(lián)網(wǎng)惟一能夠替代IPv4的核心協(xié)議已經(jīng)得到了業(yè)界的廣泛認(rèn)同。IPv6地址逐漸替代即將枯竭的IPv4地址已成為互聯(lián)網(wǎng)發(fā)展的必然趨勢(shì)，也是目前互聯(lián)網(wǎng)向下一代互聯(lián)網(wǎng)過(guò)渡的重要?dú)v史時(shí)期。

雖然IPv6提供了巨大的地址空間，與IPv4相比，IPv6在其他方面也有很多改進(jìn)，如IPv6的報(bào)頭更加簡(jiǎn)潔，移動(dòng)IPv6在入境過(guò)濾（ingress filtering）、三角路由、傳輸效率等方面也有很好的改進(jìn)等。但是，IPv6協(xié)議與IPv4協(xié)議并不兼容，IPv6的報(bào)頭結(jié)構(gòu)、報(bào)頭長(zhǎng)度等都與IPv4有著很大的不同，業(yè)務(wù)應(yīng)用對(duì)于IPv4和IPv6協(xié)議的使用方式也都有較大的區(qū)別，這些都直接導(dǎo)致IPv4和IPv6的業(yè)務(wù)無(wú)法實(shí)現(xiàn)互通等諸多問(wèn)題。

IPv4和IPv6將會(huì)處于較長(zhǎng)時(shí)間的共存期，針對(duì)共存期中如何順利開(kāi)展IPv4和IPv6的各項(xiàng)業(yè)務(wù)，推進(jìn)IPv4向IPv6的演進(jìn)過(guò)程，已經(jīng)引起了業(yè)界的重視，除了目前研究相對(duì)成熟的雙棧技術(shù)外，在國(guó)際標(biāo)準(zhǔn)化組織IETF中的Behave[1]、Softwire[2]等工作組也積極開(kāi)展了其他相關(guān)過(guò)渡技術(shù)的討論、制定和標(biāo)準(zhǔn)化過(guò)程。

鑒于目前相關(guān)過(guò)渡技術(shù)紛繁復(fù)雜、種類多樣，本文將針對(duì)不同的應(yīng)用場(chǎng)景，總結(jié)歸納目前的相關(guān)標(biāo)準(zhǔn)，并分析其優(yōu)缺點(diǎn)及適用場(chǎng)景。

2 IPv4向IPv6過(guò)渡場(chǎng)景分析

IPv4向IPv6過(guò)渡場(chǎng)景可以從三個(gè)層面的協(xié)議類型進(jìn)行描述：通信起點(diǎn)、網(wǎng)絡(luò)和通信終點(diǎn)。

對(duì)于通信起點(diǎn)和通信終點(diǎn)而言，通常包括終端的操作系統(tǒng)協(xié)議類型和應(yīng)用程序的協(xié)議類型。目前，常用的操作系統(tǒng)（如Windows 7、Vista等）都已經(jīng)能夠支持IPv4/IPv6雙棧；支持IPv6的應(yīng)用程序則既需要應(yīng)用程序自身能夠支持IPv6的socket調(diào)用，又需要操作系統(tǒng)能夠提供IPv6的支持。通常支持IPv6的應(yīng)用程序需要調(diào)用操作系統(tǒng)中與IPv6相關(guān)的系統(tǒng)調(diào)用（即操作系統(tǒng)內(nèi)核必須支持IPv6），但相反，一個(gè)支持IPv6的操作系統(tǒng)并不意味著該操作系統(tǒng)中的應(yīng)用程序就能夠支持IPv6。目前支持IPv6的應(yīng)用程序主要包括主流的瀏覽器（如IE、Mozilla Firefox等）、部分 FTP客戶端（如 FlashFXP）、SSH客戶端（如putty）、BT 軟件（如 utorrent）等。此外，部分手機(jī)終端所支持的協(xié)議類型還與手機(jī)芯片所支持的協(xié)議類型指令集相關(guān)，若芯片無(wú)法支持IPv6指令集，則該手機(jī)終端也無(wú)法支持IPv6協(xié)議棧。

為了統(tǒng)一描述通信起點(diǎn)/終點(diǎn)的協(xié)議類型，本文以數(shù)據(jù)報(bào)文在傳輸至通信起點(diǎn)/終點(diǎn)邊界時(shí)的類型來(lái)進(jìn)行定義。若該數(shù)據(jù)包為IPv6的數(shù)據(jù)報(bào)文，則稱該場(chǎng)景中的通信起點(diǎn)/終點(diǎn)為IPv6類型；否則，若該數(shù)據(jù)包為IPv4的數(shù)據(jù)報(bào)文，則稱該場(chǎng)景中的通信起點(diǎn)/終點(diǎn)為IPv4類型。通常，支持雙棧的應(yīng)用程序（操作系統(tǒng)）既能發(fā)送/接收IPv4數(shù)據(jù)報(bào)文，也能發(fā)送/接收IPv6數(shù)據(jù)報(bào)文，而且目前的操作系統(tǒng)會(huì)優(yōu)先選擇IPv6作為通信的協(xié)議類型。

對(duì)于網(wǎng)絡(luò)的協(xié)議類型而言，通常是由網(wǎng)絡(luò)設(shè)備所支持的協(xié)議類型所決定的。對(duì)于僅支持IPv4的網(wǎng)絡(luò)設(shè)備而言，只能傳輸IPv4的數(shù)據(jù)報(bào)文；對(duì)于僅支持IPv6的網(wǎng)絡(luò)設(shè)備而言，只能傳輸IPv6的數(shù)據(jù)報(bào)文；對(duì)于支持IPv4和IPv6的網(wǎng)絡(luò)設(shè)備而言，則既能傳輸IPv4的數(shù)據(jù)報(bào)文，又能傳輸IPv6的數(shù)據(jù)報(bào)文，此時(shí)網(wǎng)絡(luò)傳輸協(xié)議類型為實(shí)際在網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)報(bào)文類型。

因此，這樣就可以定義IPv4和IPv6過(guò)渡、共存時(shí)期的應(yīng)用場(chǎng)景，具體見(jiàn)表1。

本文暫不考慮傳輸網(wǎng)絡(luò)包含多種情況的應(yīng)用場(chǎng)景，如城域網(wǎng)和骨干網(wǎng)的網(wǎng)絡(luò)設(shè)備協(xié)議類型不一致的情況。

這樣，IPv4與IPv6共存時(shí)期就可以采用三段論的方式來(lái)進(jìn)行描述了。由表1可知，IPv4與IPv6的共存期包含多種應(yīng)用場(chǎng)景，與此相對(duì)應(yīng)的過(guò)渡技術(shù)也有很多種類。其中，6-4-6、4-4-6、6-4-4和4-4-4主要應(yīng)用于網(wǎng)絡(luò)為 IPv4的情況，而4-6-4、4-6-6、6-6-4和6-6-6主要應(yīng)用于網(wǎng)絡(luò)已支持IPv6傳輸能力的情況。本文后續(xù)會(huì)在全面闡述IPv6過(guò)渡方案的基礎(chǔ)上，重點(diǎn)討論網(wǎng)絡(luò)已具備IPv6傳輸能力的相關(guān)過(guò)渡技術(shù)。

表1 應(yīng)用場(chǎng)景及其描述方式

3 已有過(guò)渡技術(shù)

迄今為止，已有的IPv4/IPv6過(guò)渡技術(shù)可以分為協(xié)議翻譯類和隧道類，其中，IETF的Behave工作組主要研究協(xié)議翻譯類的技術(shù)，而Softwire工作組則主要研究隧道類的技術(shù)。

3.1 協(xié)議翻譯技術(shù)

（1）概述

IPv6過(guò)渡中的協(xié)議翻譯類技術(shù)是由IPv4的NAT技術(shù)發(fā)展而來(lái)的。在IPv4的NAT技術(shù)中，為了減少IPv4公網(wǎng)地址的消耗，NAT協(xié)議翻譯網(wǎng)關(guān)就為私網(wǎng)IPv4地址和公網(wǎng)IPv4地址建立起映射關(guān)系，通過(guò)端口的復(fù)用技術(shù)，從而達(dá)到一個(gè)公網(wǎng)地址可以由多個(gè)私網(wǎng)地址共享的效果。與此相對(duì)應(yīng)，IPv6過(guò)渡中的協(xié)議翻譯類技術(shù)就是將IPv6的數(shù)據(jù)包中的每個(gè)字段與IPv4數(shù)據(jù)包中的每個(gè)字段建立起一一映射的關(guān)系，從而在兩個(gè)網(wǎng)絡(luò)的邊緣實(shí)現(xiàn)數(shù)據(jù)報(bào)文的轉(zhuǎn)換。其應(yīng)用場(chǎng)景如圖1所示。

現(xiàn)有協(xié)議翻譯技術(shù)已有很多不同的種類。其中，根據(jù)IPv6地址空間與IPv4地址空間映射的不同方法，可分為有狀態(tài)協(xié)議翻譯和無(wú)狀態(tài)協(xié)議翻譯。其中，有狀態(tài)協(xié)議翻譯（如NAT64[3]、PNAT[4]等）是通過(guò)建立映射表的方案，將任意IPv6地址與任意IPv4地址之間建立映射關(guān)系，而無(wú)狀態(tài)協(xié)議翻譯則是通過(guò)將IPv4地址內(nèi)嵌到IPv6地址中，實(shí)現(xiàn)無(wú)狀態(tài)地址翻譯。因此，無(wú)狀態(tài)協(xié)議翻譯（如IVI[5]、DIVI[6]等）僅能訪問(wèn)具有特定格式IPv6地址的主機(jī)，而有狀態(tài)協(xié)議翻譯則能夠訪問(wèn)任意地址格式的IPv6主機(jī)。

此外，根據(jù)協(xié)議翻譯的位置，可以分為主機(jī)側(cè)協(xié)議翻譯、網(wǎng)絡(luò)側(cè)協(xié)議翻譯以及主機(jī)側(cè)和網(wǎng)絡(luò)側(cè)的協(xié)議翻譯。主機(jī)側(cè)協(xié)議翻譯（如BIS[7]、BIA[8]等）在主機(jī)中完成翻譯即可，完成端系統(tǒng)中應(yīng)用程序協(xié)議類型與網(wǎng)絡(luò)傳輸協(xié)議類型的不匹配，其應(yīng)用場(chǎng)景為4-6-6或6-4-4；網(wǎng)絡(luò)側(cè)協(xié)議翻譯（如 NAT64[3]、IVI[5]、Socks64[9]等）僅在網(wǎng)絡(luò)中部署協(xié)議翻譯網(wǎng)關(guān)即可，完成網(wǎng)絡(luò)兩側(cè)協(xié)議類型的不匹配，其應(yīng)用場(chǎng)景為6-6-4或4-4-6；而主機(jī)側(cè)和網(wǎng)絡(luò)中的兩次協(xié)議翻譯（如PNAT[4]）可應(yīng)用于4-6-4和6-4-6的應(yīng)用場(chǎng)景。

最后，根據(jù)協(xié)議翻譯技術(shù)的協(xié)議層次，可以包括網(wǎng)絡(luò)層協(xié)議翻譯（如 NAT64[3]、PNAT[4]、IVI[5]、BIS[7]）、傳輸層協(xié)議翻譯（如 TRT9）以及應(yīng)用層協(xié)議翻譯（如 BIA[8]、Socks64[10]等）。

本文在后面將介紹幾個(gè)典型的協(xié)議翻譯技術(shù)。

（2）典型的協(xié)議翻譯技術(shù)

·NAT64

NAT64是有狀態(tài)的協(xié)議翻譯技術(shù)，在網(wǎng)關(guān)中記錄了“IPv4地址＋端口”與IPv6地址的映射表會(huì)話狀態(tài)，是網(wǎng)絡(luò)層的協(xié)議翻譯技術(shù)，其應(yīng)用場(chǎng)景為6-6-4。NAT64的提出實(shí)際是用于替代NAT-PT的，NAT64僅允許IPv6主動(dòng)發(fā)起的連接，并通過(guò)將DNS-ALG的功能與NAT64網(wǎng)關(guān)的功能相分離，從而可以避免NAT-PT中一些與DNS-ALG相關(guān)的缺陷。

NAT64能夠支持純IPv6主機(jī)與純IPv4主機(jī)的直接通信，接入網(wǎng)絡(luò)可以為純IPv6網(wǎng)絡(luò)，無(wú)需更改主機(jī)側(cè)設(shè)備，并且其IPv6地址格式不受限。但是，由于NAT64是一個(gè)有狀態(tài)的協(xié)議翻譯機(jī)制，因此具有一定的可擴(kuò)展性問(wèn)題和狀態(tài)同步問(wèn)題，且需要處理ALG（應(yīng)用層網(wǎng)關(guān)）的相關(guān)問(wèn)題。

·IVI

IVI是無(wú)狀態(tài)協(xié)議翻譯技術(shù)，其中，1∶1的IVI方式僅將IPv4地址內(nèi)嵌到IPv6地址中，因此會(huì)消耗過(guò)多的IPv4公網(wǎng)地址，此時(shí)協(xié)議翻譯網(wǎng)關(guān)僅需在網(wǎng)絡(luò)側(cè)部署即可；而1∶N的IVI則通過(guò)將IPv4的地址和端口范圍同時(shí)內(nèi)嵌到IPv6地址中，從而實(shí)現(xiàn)1∶N的地址復(fù)用，此時(shí)的協(xié)議翻譯網(wǎng)絡(luò)需要在用戶側(cè)和網(wǎng)絡(luò)側(cè)同時(shí)部署，用戶側(cè)僅實(shí)現(xiàn)端口的有狀態(tài)映射，而網(wǎng)絡(luò)側(cè)則可以實(shí)現(xiàn)無(wú)狀態(tài)地址映射。

IVI能夠?qū)崿F(xiàn)網(wǎng)絡(luò)核心無(wú)狀態(tài)處理，報(bào)文轉(zhuǎn)發(fā)高效，實(shí)現(xiàn)簡(jiǎn)單。但是，由于IVI中需要將IPv4地址內(nèi)嵌到IPv6中，因此，IPv6地址格式比較受限，在1∶1的IVI會(huì)消耗過(guò)多的IPv4地址，而在1∶N的IVI中則又需要在用戶側(cè)有一定的更改，并且也需要處理ALG的相關(guān)問(wèn)題。

（3）總結(jié)

目前，協(xié)議翻譯技術(shù)仍處在發(fā)展期，可用的成熟技術(shù)相對(duì)較少。下面總結(jié)協(xié)議翻譯技術(shù)存在的幾個(gè)關(guān)鍵問(wèn)題。

·復(fù)雜性：由于協(xié)議翻譯技術(shù)都需要單獨(dú)處理每個(gè)報(bào)文的翻譯，因此不可避免需要處理ALG、DNS翻譯、分段等問(wèn)題，實(shí)現(xiàn)較為復(fù)雜。此外，有狀態(tài)協(xié)議翻譯還需要進(jìn)一步處理狀態(tài)的維護(hù)、同步等各種問(wèn)題，因此，實(shí)現(xiàn)就更為復(fù)雜。

·適用范圍：協(xié)議翻譯技術(shù)由于其本身的復(fù)雜性，通常部署于局部網(wǎng)絡(luò)或中小型網(wǎng)絡(luò)的邊緣，以減小協(xié)議翻譯系統(tǒng)的負(fù)擔(dān)。

·有狀態(tài)與無(wú)狀態(tài)協(xié)議翻譯選擇：考慮到系統(tǒng)實(shí)現(xiàn)的復(fù)雜度，應(yīng)盡可能使用無(wú)狀態(tài)協(xié)議翻譯技術(shù)。但是，由于無(wú)狀態(tài)協(xié)議翻譯僅能使用具有特定地址格式的地址，因此，對(duì)于運(yùn)營(yíng)商可控的地址部分（如用戶的地址和一些自營(yíng)業(yè)務(wù)的地址），可以使用無(wú)狀態(tài)協(xié)議翻譯中的特定格式來(lái)實(shí)現(xiàn)，而對(duì)于訪問(wèn)其他一些不可控的IPv6地址，則只能使用有狀態(tài)協(xié)議翻譯來(lái)輔助實(shí)現(xiàn)。

·ALG問(wèn)題：協(xié)議翻譯方案中，ALG是目前存在的最為主要的問(wèn)題，維護(hù)成本高、且較難使用硬件來(lái)實(shí)現(xiàn)，對(duì)設(shè)備的性能要求也比較高。因此，在協(xié)議翻譯器中，可考慮僅實(shí)現(xiàn)最為基本應(yīng)用的ALG轉(zhuǎn)換，對(duì)于其他復(fù)雜的轉(zhuǎn)換，可以采用其他方式來(lái)實(shí)現(xiàn)。

3.2 隧道技術(shù)

（1）概述

隧道類技術(shù)是指將另外一個(gè)協(xié)議數(shù)據(jù)包的報(bào)頭直接封裝在原數(shù)據(jù)包報(bào)頭前，從而可以實(shí)現(xiàn)在不同協(xié)議的網(wǎng)絡(luò)上直接進(jìn)行傳輸。其應(yīng)用場(chǎng)景如圖2所示。

在隧道類技術(shù)中，通過(guò)不同協(xié)議類型數(shù)據(jù)包的封裝和解封裝可以方便地實(shí)現(xiàn)數(shù)據(jù)包在不同協(xié)議類型網(wǎng)絡(luò)中的傳輸穿越。因此，隧道方式相比協(xié)議翻譯而言能夠較為方便地實(shí)現(xiàn)原有流量的承載。

在隧道類技術(shù)中，根據(jù)其穿越的不同網(wǎng)絡(luò)類型，又可以分為 IPv6-over-IPv4 類隧道（圖 2（a））和 IPv4-over-IPv6 類隧道（圖 2（b）），其中，支持 IPv6-over-IPv4的隧道類型較多，包括已經(jīng)成為標(biāo)準(zhǔn)的 6to4[11]、6over4[12]、ISATAP[13]、TSP[14]、Teredo[15]、6PE[16]等 ，而支持 IPv4-over-IPv6 的隧道類型目前基本還都處于草案階段，如DS-Lite[17]、A+P[18]、TSP[14]等。

此外，根據(jù)隧道封裝的協(xié)議層次，又可以分為應(yīng)用層隧道、傳輸層隧道（TSP）以及網(wǎng)絡(luò)層隧道（DS-Lite、A+P等）。其中，應(yīng)用層隧道的隧道報(bào)頭通常包括以太頭、IP頭、TCP/UDP頭和應(yīng)用層的標(biāo)識(shí)頭；傳輸層隧道的隧道報(bào)頭通常包括以太頭、IP頭、TCP/UDP頭；而網(wǎng)絡(luò)層隧道的隧道報(bào)頭則通常包括以太頭和IP頭。

本文在后面將介紹幾個(gè)典型的IPv4-over-IPv6隧道技術(shù)。

（2）典型的隧道技術(shù)

·DS-Lite

DS-Lite是一個(gè)網(wǎng)絡(luò)層的IPv4 over IPv6隧道，通過(guò)將IPv4流量封裝在IPv6隧道中進(jìn)行傳輸，接入網(wǎng)絡(luò)為IPv6單棧，可以使用IPv6地址對(duì)數(shù)據(jù)報(bào)文進(jìn)行惟一標(biāo)識(shí)，并且避免了CPE側(cè)的NAT轉(zhuǎn)換。DS-Lite僅在AFTR側(cè)做一次NAT轉(zhuǎn)換，對(duì)IPv6地址無(wú)格式限制。

DS-Lite隧道方式取消了用戶CPE側(cè)的NAT轉(zhuǎn)換，從而實(shí)現(xiàn)了網(wǎng)絡(luò)中僅保留一次NAT轉(zhuǎn)換，簡(jiǎn)化了IPv4地址的分配與管理，終端用戶可使用任意IPv4私網(wǎng)地址。該隧道建立的過(guò)程無(wú)需進(jìn)行協(xié)商，且接入網(wǎng)絡(luò)可以僅為純IPv6單棧。但是，DS-Lite也存在一定的局限性，如DS-Lite必須對(duì)用戶側(cè)的CPE做一定的更改，在AFTR（協(xié)議地址族轉(zhuǎn)換路由器）網(wǎng)關(guān)上需維護(hù)大量的NAT表項(xiàng)，具有可擴(kuò)展性和狀態(tài)的同步問(wèn)題，并且無(wú)法支持由通信對(duì)端發(fā)起的連接。

·A+P

A+P也是一個(gè)網(wǎng)絡(luò)層的IPv4 over IPv6的隧道，采用端口靜態(tài)劃分的方式復(fù)用IPv4地址，將網(wǎng)絡(luò)核心側(cè)的NAT轉(zhuǎn)移到CPE側(cè)，從而實(shí)現(xiàn)網(wǎng)絡(luò)核心側(cè)無(wú)狀態(tài)的數(shù)據(jù)轉(zhuǎn)發(fā)。在A+P中，將IPv4地址和端口范圍內(nèi)嵌到IPv6地址中，IPv6地址格式受限，且有特定前綴。

A+P的方案可實(shí)現(xiàn)網(wǎng)絡(luò)核心無(wú)狀態(tài)轉(zhuǎn)換，并且可以復(fù)用IPv4地址。隧道可自動(dòng)建立，無(wú)協(xié)商過(guò)程。但是其缺點(diǎn)在于一方面CPE需進(jìn)行一定的升級(jí)，并且IPv6地址格式有一定的限制。

·TSP

TSP是基于隧道代理（tunnel broker）的一種信令協(xié)議，通過(guò)在兩個(gè)端點(diǎn)間進(jìn)行參數(shù)協(xié)商建立隧道，包括IPv4 over IPv6和IPv6 over IPv4兩種類型，隧道的層次也可以通過(guò)協(xié)商確定，包括網(wǎng)絡(luò)層和傳輸層UDP隧道。此時(shí)的IPv6地址為任意格式的地址，IPv4地址為公網(wǎng)地址。因此，若需要使用IPv4私有地址，則還需要額外增加NAT設(shè)備。

（3）總結(jié)

目前隧道技術(shù)（尤其是IPv4-over-IPv6）仍處在發(fā)展期。隧道技術(shù)比較適合于4-6-4和6-4-6的應(yīng)用場(chǎng)景，實(shí)現(xiàn)較為簡(jiǎn)單。為了減少IP地址的消耗，隧道技術(shù)必須能夠?qū)崿F(xiàn)IP地址的復(fù)用。目前常見(jiàn)的IP地址復(fù)用方式通常包括基于LSN的動(dòng)態(tài)地址復(fù)用以及基于端口范圍（port range[19]）的靜態(tài)地址復(fù)用。動(dòng)態(tài)地址復(fù)用的方式需要引入運(yùn)營(yíng)級(jí)NAT，在不同網(wǎng)絡(luò)邊界處實(shí)現(xiàn)私網(wǎng)地址與公網(wǎng)地址的轉(zhuǎn)換與映射，此時(shí)需保留連接的狀態(tài)表。而靜態(tài)地址復(fù)用的方式則通過(guò)劃分端口空間使得用戶能夠通過(guò)不同的端口空間來(lái)區(qū)分共享同一個(gè)公網(wǎng)IPv4地址，可以實(shí)現(xiàn)網(wǎng)絡(luò)核心側(cè)無(wú)狀態(tài)地址復(fù)用。

4 結(jié)束語(yǔ)

在IPv4向IPv6的過(guò)渡時(shí)期，目前可應(yīng)用于IPv4與IPv6共存時(shí)期的相關(guān)過(guò)渡技術(shù)復(fù)雜多樣，其中，協(xié)議翻譯技術(shù)的優(yōu)點(diǎn)在于部署簡(jiǎn)單和應(yīng)用場(chǎng)景多樣，但是其缺點(diǎn)在于實(shí)現(xiàn)的復(fù)雜度較高。與此相對(duì)應(yīng)，隧道技術(shù)實(shí)現(xiàn)較為簡(jiǎn)單，但是其缺點(diǎn)在于應(yīng)用場(chǎng)景較為單一。因此，在解決同種協(xié)議應(yīng)用的訪問(wèn)時(shí)（如4-6-4或6-4-6的場(chǎng)景中）推薦使用隧道的方式來(lái)實(shí)現(xiàn)，而對(duì)于不同種協(xié)議的訪問(wèn)時(shí)（如6-6-4或4-6-6）則推薦采用協(xié)議翻譯的方式。此外，由于各類過(guò)渡技術(shù)對(duì)于網(wǎng)絡(luò)中的狀態(tài)維護(hù)、地址分配管理、路由規(guī)劃等都會(huì)帶來(lái)不同的要求與影響，因此，在網(wǎng)絡(luò)的實(shí)際應(yīng)用中，應(yīng)綜合考慮各類技術(shù)對(duì)于網(wǎng)絡(luò)部署及現(xiàn)網(wǎng)改造的影響，從而實(shí)現(xiàn)IPv4向IPv6的平滑過(guò)渡。

1 http://tools.ietf.org/wg/behave/

2 http://tools.ietf.org/wg/softwire/

3 BagnuloM,MatthewsP,vanBeijnum I.StatefulNAT64:network address and protocol translation from IPv6 clients to IPv4 servers.Draft-ietf-behave-v6v4-xlate-stateful-11 (work in progress),March 30,2010

4 Huang B,Deng H.Prefix NAT:host based IPv6 translation.Draft-huang-behave-pnat-01(work in progress),February 19,2010

5 Li X,Bao C,Chen M,Zhang H.The cernet IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.Draft-xli-behave-ivi-07(work in progress),January 6,2010

6 Li X,Bao C,Zhang H.Address-sharing stateless double IVI.Draft-xli-behave-divi-01(work in process),October 26,2009

7 Tsuchiya K,Higuchi H,Atarashi Y.Dual stack hosts using the"Bump-In-the-Stack"technique(BIS).RFC2767,February,2000

8 Lee S,Shin M-K,Kim Y-J,et al.Dual stack hosts using"Bump-in-the-API"(BIA).RFC 3338,October,2002

9 Hagino J,Yamamoto K.An IPv6-to-IPv4 transportrelay translator.RFC3142

10 Kitamura H.A socks-based IPv6/IPv4 gateway mechanism(socks 64).RFC 3089,April,2001

11 Carpenter B,Moore K.Connection of IPv6 domains via IPv4 clouds.RFC 3056

12 Carpenter B,Jung C.Transmission of IPv6 over IPv4 domains without explicit tunnels.RFC 2529

13 Templin F,Gleeson T,Talwar M,et al.Intra-site automatic tunnel addressing protocol(ISATAP).RFC 4214

14 Blanchet M,Parent F.IPv6 tunnel broker with the tunnel setup protocol(TSP).RFC 5572

15 Huitema C.Teredo:tunneling IPv6 over UDP through network address translations(NATs).RFC 4380

16 De Clercq J,Ooms D,Prevost S,et al.Connecting IPv6 islands over IPv4 MPLS using IPv6 provider edge routers (6PE).RFC 4798

17 Boucadair M,Jacquenet C,Grimault J L,et al.Deploying dual-stack lite (DS-lite)in IPv6 network.Draft-boucadair-dsliteinterco-v4v6-03(work in process),February 24,2010

18 Bush R.The A+P approach to the IPv4 address shortage.Draftymbk-aplusp-05,October 27,2009

19 Ripke A,Quittek J,Brunner M.Dynamic port range re-assignments foraddresssharing.Draft-rqb-dynamic-port-ranges-02,March8,2010