趙慧玲，陳運清，孫 瓊，王 茜

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

1 概述

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

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

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

鑒于目前相關過渡技術紛繁復雜、種類多樣，本文將針對不同的應用場景，總結歸納目前的相關標準，并分析其優(yōu)缺點及適用場景。

2 IPv4向IPv6過渡場景分析

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

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

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

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

因此，這樣就可以定義IPv4和IPv6過渡、共存時期的應用場景，具體見表1。

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

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

表1 應用場景及其描述方式

3 已有過渡技術

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

3.1 協(xié)議翻譯技術

（1）概述

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

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

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

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

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

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

·NAT64

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

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

·IVI

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

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

（3）總結

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

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

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

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

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

3.2 隧道技術

（1）概述

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

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

在隧道類技術中，根據(jù)其穿越的不同網(wǎng)絡類型，又可以分為 IPv6-over-IPv4 類隧道（圖 2（a））和 IPv4-over-IPv6 類隧道（圖 2（b）），其中，支持 IPv6-over-IPv4的隧道類型較多，包括已經(jīng)成為標準的 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é)議層次，又可以分為應用層隧道、傳輸層隧道（TSP）以及網(wǎng)絡層隧道（DS-Lite、A+P等）。其中，應用層隧道的隧道報頭通常包括以太頭、IP頭、TCP/UDP頭和應用層的標識頭；傳輸層隧道的隧道報頭通常包括以太頭、IP頭、TCP/UDP頭；而網(wǎng)絡層隧道的隧道報頭則通常包括以太頭和IP頭。

本文在后面將介紹幾個典型的IPv4-over-IPv6隧道技術。

（2）典型的隧道技術

·DS-Lite

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

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

·A+P

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

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

·TSP

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

（3）總結

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

4 結束語

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

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