摘要：分析了當前比較成熟的隧道和翻譯過渡技術(shù)，主要包括主干網(wǎng)隧道過渡技術(shù)、接入網(wǎng)隧道過渡技術(shù)、接入網(wǎng)翻譯過渡技術(shù)。針對過渡場景及其解決方案各不相同，認為在過渡過程中應(yīng)當充分考慮網(wǎng)絡(luò)的特征與現(xiàn)狀。以主干網(wǎng)和接入網(wǎng)為主線，給出了各場景適用的技術(shù)方案，包括主干網(wǎng)的IPv6過渡場景、接入網(wǎng)的IPv6過渡場景、互聯(lián)網(wǎng)內(nèi)容提供商過渡場景。

關(guān)鍵詞： 下一代互聯(lián)網(wǎng)；過渡技術(shù)；過渡場景

Abstract： In this paper， we discuss more mature IPv6 transition technologies related to the backbone tunnel， access network tunnel， and access network translation. We suggest that it is necessary to consider the characteristics and status quo of the network in the transition process. We analyze the technology applicable to a backbone IPv6 transition scenario， an access network IPv6 transition scenario， and an Internet content provider transition scenario.

Key words： next generation Internet； transition technology； transition scenarios

1 IPv6過渡技術(shù)的背景

IPv4互聯(lián)網(wǎng)已在全球范圍取得了巨大的成功，但隨著互聯(lián)網(wǎng)規(guī)模的持續(xù)增長，IPv4地址資源日益短缺。采用私有IP地址的網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）技術(shù)雖然可以緩解地址短缺壓力，但是破壞了互聯(lián)網(wǎng)端到端特性，影響了許多互聯(lián)網(wǎng)應(yīng)用的推廣。IPv6具有地址空間巨大、改進了地址格式和路由匯聚特性等諸多優(yōu)點，是下一代互聯(lián)網(wǎng)中取代IPv4的最佳選擇。然而IPv6與IPv4不兼容，因而在IPv4向IPv6過渡時期，IPv4與IPv6網(wǎng)絡(luò)共存，帶來了IPv4/IPv6互聯(lián)與穿越等基本需求，產(chǎn)生了異構(gòu)路由、地址映射、狀態(tài)維護與可擴展性等問題。如何平穩(wěn)實現(xiàn)互聯(lián)網(wǎng)向IPv6過渡，已經(jīng)成為全球下一代互聯(lián)網(wǎng)發(fā)展的重大技術(shù)挑戰(zhàn)之一。

針對IPv6過渡問題，目前國際上提出了許多過渡方案。這些技術(shù)方案針對不同的網(wǎng)絡(luò)場景、用戶的需求和過渡階段提出，其技術(shù)思想也不盡相同。過渡技術(shù)從整體上可以劃分為雙棧技術(shù)、隧道技術(shù)和翻譯技術(shù)。雙棧過渡技術(shù)需要節(jié)點上并行維護IPv4和IPv6協(xié)議棧，代價高，不能解決IPv4地址耗竭的問題，因此對隧道和翻譯過渡技術(shù)的研究在互聯(lián)網(wǎng)工程任務(wù)組已經(jīng)成為了重點和熱點。

隧道技術(shù)通過對報文的封裝、解封裝，使得兩個同構(gòu)網(wǎng)絡(luò)能夠在一個異構(gòu)網(wǎng)絡(luò)的兩邊橋接起來從而實現(xiàn)相互通信。通過隧道技術(shù)使底層承載網(wǎng)絡(luò)保持單棧，僅將隧道端點的地址簇邊界路由器升級成雙棧，即可實現(xiàn)數(shù)據(jù)報文跨異構(gòu)網(wǎng)絡(luò)的透傳。隧道技術(shù)具有保持端到端特性，對終端上層應(yīng)用透明，對底層網(wǎng)絡(luò)獨立的優(yōu)勢。早期的隧道方案包括手工配置隧道、6to4[1]、6PE[2]、ISATAP[3]、Teredo[4]等。近年來，IETF Softwire工作組針對主干網(wǎng)和接入網(wǎng)研究并制訂了一系列的隧道過渡標準。

翻譯技術(shù)是指將IP數(shù)據(jù)包在IPv4和IPv6兩種協(xié)議簇之間的轉(zhuǎn)換，其可以分為有狀態(tài)和無狀態(tài)兩種。有狀態(tài)翻譯是指在翻譯設(shè)備中需要保存動態(tài)信息或是在接收轉(zhuǎn)發(fā)報文時需要新建或者修改翻譯設(shè)備中的數(shù)據(jù)結(jié)構(gòu)，反之，如果都不需要則稱為無狀態(tài)翻譯。翻譯技術(shù)能夠直接、高效地實現(xiàn)IPv4/IPv6的互通。早期的翻譯技術(shù)包括SIIT[5]、NAT-PT[6]等，目前翻譯相關(guān)標準的制訂主要在behave工作組進行?，F(xiàn)階段比較成熟的翻譯技術(shù)包括NAT64[7]、IVI[8]等。由于翻譯技術(shù)本身的限制以及IPv6地址空間遠大于IPv4地址空間等因素，這些翻譯技術(shù)對過渡場景的適用有著一定的局限性。

2 主干網(wǎng)隧道過渡技術(shù)

6to4用于解決IPv6孤島穿越IPv4網(wǎng)絡(luò)實現(xiàn)相互通信，以及與IPv6 Internet通信。這是通過6to4邊界路由器（連接IPv6子網(wǎng)和IPv4網(wǎng)絡(luò)）采用無狀態(tài)自動隧道實現(xiàn)。6to4將固定前綴2002：：/16劃分成多個IPv6網(wǎng)絡(luò)前綴，而這些網(wǎng)絡(luò)前綴在中繼處無法聚合，將極大地擴張路由器路由表規(guī)模，從而帶來IPv6可擴展性問題。

網(wǎng)狀軟線Softwire Mesh[9-11]采用的也是一種網(wǎng)狀穿越場景下路由器到路由器的隧道機制，它應(yīng)用的場景是內(nèi)部IP（I-IP）主干網(wǎng)下外部IP（E-IP）客戶網(wǎng)間的互聯(lián)，包括IPv4承載IPv6（IPv4-over-IPv6）和IPv6承載IPv4（IPv6-over-IPv4）兩類場景。Softwire Mesh通過擴展MP-BGP協(xié)議，將E-IP目的前綴與I-IP封裝目的地址形成映射，實現(xiàn)跨異構(gòu)網(wǎng)絡(luò)路由信息傳遞。映射表的大小不會超過E-IP轉(zhuǎn)發(fā)表，所以查表時間在可以接受的范圍之內(nèi)。網(wǎng)狀軟線保持了4/6獨立編址，具有良好的可擴展性，可適用于大規(guī)模網(wǎng)絡(luò)；支持多種隧道類型，包括IP-IP、GRE、MPLS、L2TP、IPsec等；通過擴展邊界網(wǎng)關(guān)協(xié)議（BGP）提供了通用的信令機制支持；為主干網(wǎng)的過渡提供了重要的解決方案。

3 接入網(wǎng)隧道過渡技術(shù)

6RD[12-13]技術(shù)面向IPv6網(wǎng)絡(luò)穿越IPv4接入網(wǎng)與IPv6互聯(lián)網(wǎng)通信的場景，將6to4隧道應(yīng)用到星型IPv6-over-IPv4場景中。6RD采用無狀態(tài)封裝，并且在6to4技術(shù)的基礎(chǔ)上擴展，使用因特網(wǎng)業(yè)務(wù)提供商（ISP）實際可變前綴（NSP），按照NSP+{IPv4}：：/的格式組成IPv6前綴，再生成IPv6地址。6RD具有無狀態(tài)和簡單的特性，但由于IPv6地址與IPv4地址耦合，6RD同樣存在IPv6可擴展性的問題。

近年來，IPv6接入網(wǎng)逐漸增多，但用戶和應(yīng)用仍大量留在IPv4中。由于IPv6接入網(wǎng)中的IPv4應(yīng)用或終端仍需要訪問IPv4互聯(lián)網(wǎng)，IPv4-over-IPv6場景逐漸增多。為緩解IPv4地址緊缺的壓力，該場景下增加了IPv4地址共享的考慮?；诘刂饭蚕矸绞胶陀袩o狀態(tài)維護兩個維度，IETF提出3類IPv4-over-IPv6過渡方案[14]。

Dual-Stack Lite[15]方案采用運營商級別的網(wǎng)絡(luò)地址轉(zhuǎn)換（CGN）和有狀態(tài)封裝技術(shù)。在該機制中公有地址在CGN處集中控制，本地網(wǎng)絡(luò)需要使用私有IPv4地址，而隧道匯聚點即CGN負責將封裝在IPv6中的IPv4報文解封裝并進行NAT轉(zhuǎn)換。該方案能有效地緩解IPv4地址不足的問題，但處于較高位置的NAT會帶來狀態(tài)維護上的巨大開銷，并且由于NAT的阻隔，外部網(wǎng)絡(luò)無法主動發(fā)起對IPv6域內(nèi)IPv4主機的訪問。

4over6機制將公有地址的分配、共享和有狀態(tài)封裝有機地結(jié)合起來。Public 4over6[16]方案通過DHCPv4-over-IPv6技術(shù)跨越IPv6接入網(wǎng)動態(tài)地分配完整的公有IPv4地址[17]。用戶獲取公有地址后可以直接將IPv4報文經(jīng)4over6隧道發(fā)送到運營商側(cè)的隧道匯聚點，由匯聚點進行解封裝和IPv4轉(zhuǎn)發(fā)。由于該機制用戶側(cè)無NAT，因此支持外部網(wǎng)絡(luò)對域內(nèi)主機或服務(wù)器的訪問。

4over6機制的狀態(tài)維護從每流的規(guī)模降到每用戶的規(guī)模，從而減輕隧道匯聚點的性能壓力；將公有地址下放至用戶側(cè)，可以保持端到端的特性；沒有應(yīng)用層翻譯的問題，并且可以保持通信的雙向透明性[18]。

為了進一步提高IPv4地址的復(fù)用率，Public 4over6的擴展方案lightweight 4over6[19]方案可以根據(jù)實際需求分配適當?shù)亩丝诜秶ㄟ^劃分端口段的方式來共享提高IPv4地址利用率。

IPv4-over-IPv6的第三類解決方案是4RD[20]和MAP-E[21]，采用的是包含地址共享的無狀態(tài)封裝方式。支持該類方案將IPv4地址和端口段信息內(nèi)嵌入IPv6地址，通過IPv4/IPv6地址映射算法[22]實現(xiàn)雙向地址解析。通過計算獲取的地址進行路由和封裝/解封裝。通過將IPv4與IPv6地址進行結(jié)合，該機制實現(xiàn)了無狀態(tài)維護，這使得該類方案在狀態(tài)維護上優(yōu)于DS-Lite和4over6方案。然而，IPv4地址與IPv6地址的耦合性將會給IPv4/IPv6網(wǎng)絡(luò)的規(guī)劃和運行帶來較大的限制。

4 接入網(wǎng)翻譯過渡技術(shù)

接入網(wǎng)翻譯技術(shù)主要包括有狀態(tài)和無狀態(tài)翻譯。NAT64采用有狀態(tài)翻譯方式，明確了IPv4主機地址映射到IPv6時使用固定前綴64：FF9B：：/96。NAT64細化了DNS尋址的方法，將DNS翻譯的功能獨立為DNS64設(shè)備。NAT64方案的適用場景包括IPv6網(wǎng)絡(luò)訪問IPv4互聯(lián)網(wǎng)、IPv6互聯(lián)網(wǎng)訪問IPv4網(wǎng)絡(luò)、IPv6網(wǎng)絡(luò)訪問IPv4網(wǎng)絡(luò)。狀態(tài)維護的特性決定了它不可能適用于IPv6互聯(lián)網(wǎng)訪問IPv4互聯(lián)網(wǎng)的訪問場景。而對IPv4訪問IPv6的4種場景，現(xiàn)有的一些機制并不可行。

IVI機制為無狀態(tài)翻譯技術(shù)采用網(wǎng)絡(luò)專用的可變前綴（NSP），用NSP+IPv4地址+后綴的形式組建IPv6地址。IVI機制的路由可擴展和尋址問題都得到了解決，同時具有高性能、支持雙向無狀態(tài)通信的優(yōu)點，適用于IPv6網(wǎng)絡(luò)與IPv4網(wǎng)絡(luò)互通的場景。然而IVI機制本身仍需要消耗IPv6用戶量級的IPv4地址，因此其并不適合大規(guī)模部署。對此IVI又給出了支持IPv4地址復(fù)用的擴展方案，每個用戶只占用1個IPv4地址的部分端口空間。這就需要主機端或用戶終端設(shè)備（CPE）端進行相應(yīng)的端口映射。

5 場景分析與適用技術(shù)方案

IPv6過渡符合下一代互聯(lián)網(wǎng)的發(fā)展方向，但過渡場景及其解決方案各不相同，在過渡過程中應(yīng)當充分考慮網(wǎng)絡(luò)的特征與現(xiàn)狀。本文以主干網(wǎng)和接入網(wǎng)為主線，對各種IPv4/IPv6過渡的場景進行描述和分析，供ISP和ICP進行實際的決策和部署時作參考。

5.1 主干網(wǎng)的IPv6過渡場景

主干網(wǎng)向上連接為自己提供傳輸服務(wù)的上級供應(yīng)商網(wǎng)絡(luò)，向下可連接各個邊緣網(wǎng)絡(luò)，同時主干網(wǎng)還與同級的其他主干網(wǎng)相連[23]。主干網(wǎng)基本過渡場景如圖1所示。主干網(wǎng)的主要任務(wù)是提供IPv4和IPv6的接入和傳輸服務(wù)，無論是IPv4分組還是IPv6分組都能夠通過所接入的主干網(wǎng)轉(zhuǎn)發(fā)到正確的目的地。為達到這一目的，可以將主干網(wǎng)升級成雙棧，但是開銷巨大；對于單棧的主干網(wǎng)，則需要借助過渡技術(shù)來同時提供IPv4和IPv6的傳輸服務(wù)。

主干網(wǎng)的過渡場景主要包括IPv6客戶網(wǎng)穿越IPv4主干網(wǎng)與IPv6 Internet互通和IPv4客戶網(wǎng)穿越IPv6主干網(wǎng)與IPv4 Internet互通兩類?，F(xiàn)有的一些IPv4主干網(wǎng)可能需要提供IPv6傳輸服務(wù)，出現(xiàn)IPv6-over-IPv4過渡場景，此時可以只將主干網(wǎng)邊界路由器升級成雙棧，而核心路由器仍保持IPv4單棧，使用6to4或Softwire Mesh技術(shù)等來提供IPv6傳輸服務(wù)。

隨著下一代互聯(lián)網(wǎng)的發(fā)展，純IPv6主干網(wǎng)逐漸建成。但是IPv4客戶網(wǎng)以及IPv4 Internet仍會長期存在，為促進IPv6主干網(wǎng)的利用率，IPv4-over-IPv6過渡場景越來越多，可以利用Softwire Mesh技術(shù)使IPv6主干網(wǎng)能夠提供IPv4的傳輸服務(wù)。這樣可以將IPv4流量引入到IPv6主干網(wǎng)中，減輕IPv4網(wǎng)絡(luò)的負擔，并逐漸取代IPv4網(wǎng)絡(luò)，也可以積累較多的IPv6運營經(jīng)驗。

5.2 接入網(wǎng)的IPv6過渡場景

接入網(wǎng)一方面向下為用戶側(cè)設(shè)備提供接入，另一方面向上接入Internet。在過渡時期，接入網(wǎng)需要為各種終端用戶設(shè)備和服務(wù)器設(shè)備提供IPv4和IPv6接入服務(wù)。接入網(wǎng)的基本場景如圖2所示。接入網(wǎng)絡(luò)的用戶可以是直接以與接入網(wǎng)相同地址協(xié)議簇形式接入，也可能是用戶側(cè)設(shè)備（CPE）接入網(wǎng)絡(luò)并且在其后連接了不同地址協(xié)議簇的主機；在接入網(wǎng)絡(luò)另一側(cè)的接入網(wǎng)邊界路由器（BR）接入Internet。若接入網(wǎng)為雙棧，則可以利用已有的IPv4和IPv6同時為用戶提供雙棧的接入環(huán)境。但是采用雙棧開銷巨大，而且并沒有解決IPv4地址緊缺的問題，因此在過渡時期通過單棧的接入網(wǎng)結(jié)合過渡技術(shù)為用戶提供IPv4和IPv6服務(wù)。

由于IPv4地址的耗竭以及中國國家的大力推動，IPv6接入網(wǎng)將逐漸建成。在此IPv6接入網(wǎng)中的用戶會有與IPv4或IPv6 Internet交互的需求。用戶設(shè)備可以直接以IPv6接入IPv6接入網(wǎng)，此時可以正常的與IPv6 Internet通信；但是訪問IPv4 Internet時，出現(xiàn)異構(gòu)網(wǎng)絡(luò)直連的過渡場景。IPv6應(yīng)用訪問IPv4 Internet場景如圖3所示。此時需要IVI或NAT64等翻譯技術(shù)來實現(xiàn)。

IPv6接入網(wǎng)中的用戶也可能使用IPv4應(yīng)用或者一部分IPv4用戶通過CPE接入IPv6網(wǎng)絡(luò)。若用戶訪問IPv4 Internet則會出現(xiàn)如圖4所示的IPv4-over-IPv6過渡場景。此時可以借助Public 4over6、Lightweight 4over6等隧道解決方案，用戶設(shè)備（CPE或直連設(shè)備）作為隧道的發(fā)起點（TI），接入網(wǎng)另一側(cè)的BR設(shè)備作為隧道的匯聚點（TC）。用戶的IPv4分組在TI上根據(jù)具體方案進行封裝，TI再將封裝好的分組通過IPv6接口發(fā)往TC，TC收到此分組后進行解封裝發(fā)往IPv4 Internet。另外，該場景下可以使用MAP-E無狀態(tài)隧道技術(shù)或者是兩次翻譯方案。

若IPv6資源的豐富，而IPv6接入網(wǎng)中某些終端的上層應(yīng)用由于技術(shù)等原因仍然使用的是IPv4，則會產(chǎn)生IPv4應(yīng)用與IPv6 Internet進行通信的場景，如圖5所示。在這種場景下需要進行用戶側(cè)的翻譯。根據(jù)翻譯點的不同所使用的翻譯技術(shù)也有所不同。如果是直連設(shè)備，則翻譯點就在直連設(shè)備上。此時可以使用主機側(cè)翻譯技術(shù)[24]；如果是CPE設(shè)備所連接的IPv4主機上的IPv4應(yīng)用希望與IPv6 Internet通信，那么翻譯點就在CPE上。

現(xiàn)有的已建設(shè)的接入網(wǎng)一般是IPv4單棧，出現(xiàn)的過渡場景與IPv6接入網(wǎng)的恰好相反。在此IPv4接入網(wǎng)中的用戶會有與IPv6和IPv4 Internet交互的需求。用戶設(shè)備可以直接以IPv4接入IPv4接入網(wǎng)，此時可以正常地與IPv4 Internet通信，但是訪問IPv6 Internet時，會出現(xiàn)異構(gòu)網(wǎng)絡(luò)直連的過渡場景，此時可以采用IVI等翻譯技術(shù)來實現(xiàn)。IPv4接入網(wǎng)中的用戶也可能使用IPv6應(yīng)用或者一部分用戶使用IPv6通過CPE接入IPv4網(wǎng)絡(luò)，此時用戶若訪問IPv4 Internet則會出現(xiàn)異構(gòu)網(wǎng)絡(luò)直連的過渡場景，可以借助IVI等翻譯技術(shù)來實現(xiàn)，但是并不提倡這種在全網(wǎng)都是IPv4的情況下只將終端或應(yīng)用升級成IPv6的場景；若用戶訪問IPv6 Internet則會出現(xiàn)IPv4-over-IPv6過渡場景，此時可以借助6rd等隧道過渡技術(shù)來實現(xiàn)互訪。

5.3 互聯(lián)網(wǎng)內(nèi)容提供商過渡場景

對于互聯(lián)網(wǎng)內(nèi)容提供商（ICP）而言需要為Internet提供服務(wù)，并且由于ICP的服務(wù)系統(tǒng)構(gòu)架升級相對普通用戶要困難得多，需要對其進行單獨討論。首先單棧接入網(wǎng)絡(luò)應(yīng)當為ICP提供雙棧傳輸能力，使得ICP既可以提供IPv4的服務(wù)又可以提供IPv6的服務(wù)。單棧接入網(wǎng)使用隧道技術(shù)為ICP提供雙棧環(huán)境如圖6所示。假設(shè)ICP接入的是IPvX單棧網(wǎng)絡(luò)，則其可以直接使用與接入網(wǎng)地址協(xié)議簇相同的IPvX Internet提供服務(wù)，而使用隧道技術(shù)來為IPvY Internet提供服務(wù)。

另一方面，考慮到ICP服務(wù)系統(tǒng)構(gòu)架由于技術(shù)升級等原因可能是單棧的，則可以使用翻譯技術(shù)來為異構(gòu)的網(wǎng)絡(luò)提供服務(wù)。IPv4 ICP為IPv6 Internet提供服務(wù)如圖7所示。現(xiàn)有的ICP實際上大多數(shù)只支持提供IPv4的服務(wù)，隨著IPv6規(guī)模的增大，這些ICP希望在沒有升級之前為IPv6 Internet提供服務(wù)。在這種過渡場景下可以通過在ICP側(cè)與IPv6網(wǎng)絡(luò)的接入處部署NAT64有狀態(tài)的翻譯設(shè)備實現(xiàn)互通。與此相反的是ICP升級自己的服務(wù)，最終會出現(xiàn)只能提供IPv6服務(wù)的系統(tǒng)架構(gòu)。此時IPv4 Internet可能還有一定的規(guī)模，則IPv6 ICP需要為IPv4 Internet提供服務(wù)。在這種需求場景下，可以通過在ICP側(cè)與IPv4網(wǎng)絡(luò)的接入處部署一個無狀態(tài)的翻譯設(shè)備，IVI可以很好地適應(yīng)ICP在這種場景下的需求。

6 結(jié)束語

由IPv4向IPv6平滑過渡是中國發(fā)展下一代互聯(lián)網(wǎng)的重要步驟之一，也是當前國際互聯(lián)網(wǎng)發(fā)展的大勢所趨。本文綜合介紹了在當前IPv6過渡的環(huán)境下，全球的主流過渡技術(shù)，并對各個典型過渡場景進行了分析。針對不同的過渡場景，運營商和互聯(lián)網(wǎng)內(nèi)容提供商可以選擇不同的過渡技術(shù)實現(xiàn)IPv4與IPv6的互通。通過各方的共同努力以推動下一代互聯(lián)網(wǎng)的發(fā)展。

參考文獻

[1] CARPENTER B， MOORE K. Connection of IPv6 domains via IPv4 Clouds [S]. RFC3056. 2001.

[2] CLERCQ J D， OOMS D， PREVOST S， et al. Connecting IPv6 is lands over IPv4 MPLS using IPv6 provider edge routers （6PE） [S]. RFC4798. 2007.

[3] TEMPLIN F， GLEESON T， THALER D. Intra-site automatic tunnel addressing protocol （ISATAP） [S]. RFC5214. 2008.

[4] HUITEMA C. Teredo： Tunneling IPv6 over UDP through network address translations （NATs） [S]. RFC4380. 2006.

[5] NORDMARK E. Stateless IP/ICMP translation algorithm （SIIT） [S]. RFC2765. 2000.

[6] AOUN C， DAVIES E. Reasons to move the network address translator - protocol translator （NAT-PT） to historic status [S]. RFC4966. 2007.

[7] BAGNULO M， MATTHEWS P， VAN BEIJNUM I. Stateful NAT64： Network address and protocol translation from IPv6 clients to IPv4 servers [S]. RFC6146. 2011.

[8] LI X， BAO C， CHEN M， et al. The CERNET IVI translation design and deployment for the IPv4/IPv6 coexistence and transition [S]. RFC6219. 2011.

[9] WU J， CUI Y， LI X， et al. The transition to IPv6， Part I： 4over6 for the China Education and Research Network [J]. IEEE Internet Computing， 2006，10（3）：80-85.

[10] CUI Y， WU J， LI X， et al. The transition to IPv6， Part II： The softwire mesh framework solution [J]. IEEE Internet Computing， 2006，10（5）：76-80.

[11] WU J， CUI Y， METZ C， et al. Softwire mesh framework [S]. RFC5565. 2009.

[12] DESPRES R. IPv6 rapid deployment on IPv4 infrastructures （6rd） [S]. RFC5569. 2010.

[13] TOWNSLEY M， TROAN O. IPv6 rapid deployment on IPv4 infrastructures （6rd） [S]. RFC5969， 2010.

[14] WU P， CUI Y， WU J， et al. Transition from IPv4 to IPv6： A state-of-the-art survey [J]. IEEE Communications Surveys and Tutorials， to be published.

[15] DURAND A， DROMS R， WOODYATT J， et al. Dual-stack lite broad-band deployments following IPv4 exhaustion [S]. RFC6333. 2011.

[16] CUI Y， WU J， WU P， et al. Public IPv4 over access IPv6 network [R]. draft-cui-softwire-host-4over6-05. 2011.

[17] CUI Y， WU J， WU P. DHCPv4 over IPv6 transport [R]. draft-ietf-dhc-dhcpv4-over-ipv6-05. 2012.

[18] CUI Y， DONG J， WU P， et al. Tunnel-based IPv6 transition [J]. IEEE Internet Computing， to be published.

[19] CUI Y， WU J， WU P， et al. Lightweight 4over6 in access network [R]. IETF draft. 2011.

[20] DESPRES R， PENNO R， LEE Y， et al. IPv4 residual deployment via IPv6 -- A uni?ed stateless solution （4rd） [R]. IETF draft. 2012.

[21] TROAN O， DEC W， LI X， et al. Mapping of address and port （MAP） [R]. IETF draft， 2012.

[22] TROAN O， MATSUSHIMA S， MURAKAMI T， et al. Mapping of address and port（MAP） [R]. IETF draft. 2012.

[23] 崔勇， 董江， 徐明偉， 等. IPv6過渡場景分析 [R]. 中國通信行業(yè)研究報告， 2012B7. 2012.

[24] TSUCHIYA K， HIGUCHI H， ATARASHI Y. Dual stack hosts using the bump-in-the-stack technique （BIS） [S]. RFC2767. 2000.

作者簡介

孫靜文，北京郵電大學網(wǎng)絡(luò)技術(shù)研究院寬帶網(wǎng)研究中心在讀碩士研究生；研究方向為IPv4/IPv6過渡技術(shù)、下一代互聯(lián)網(wǎng)；已發(fā)表學術(shù)論文1篇。

孫琪，北京郵電大學網(wǎng)絡(luò)技術(shù)研究院寬帶網(wǎng)研究中心在讀碩士研究生；研究方向為IPv4/IPv6過渡技術(shù)、下一代互聯(lián)網(wǎng)；已發(fā)表學術(shù)論文1篇。

吳鵬，清華大學計算機科學與技術(shù)系在讀博士研究生；研究方向為IPv4/IPv6過渡、下一代互聯(lián)網(wǎng)、網(wǎng)絡(luò)體系結(jié)構(gòu)；已發(fā)表學術(shù)論文5篇。