IPv6過(guò)渡技術(shù)場(chǎng)景分析

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

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

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過(guò)渡技術(shù)的背景

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

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

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

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

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

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

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

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

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

近年來(lái)，IPv6接入網(wǎng)逐漸增多，但用戶和應(yīng)用仍大量留在IPv4中。由于IPv6接入網(wǎng)中的IPv4應(yīng)用或終端仍需要訪問(wèn)IPv4互聯(lián)網(wǎng)，IPv4-over-IPv6場(chǎng)景逐漸增多。為緩解IPv4地址緊缺的壓力，該場(chǎng)景下增加了IPv4地址共享的考慮。基于地址共享方式和有無(wú)狀態(tài)維護(hù)兩個(gè)維度，IETF提出3類IPv4-over-IPv6過(guò)渡方案[14]。

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

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

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

為了進(jìn)一步提高IPv4地址的復(fù)用率，Public 4over6的擴(kuò)展方案lightweight 4over6[19]方案可以根據(jù)實(shí)際需求分配適當(dāng)?shù)亩丝诜秶?，通過(guò)劃分端口段的方式來(lái)共享提高IPv4地址利用率。

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

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

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

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

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

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

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

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

主干網(wǎng)的過(guò)渡場(chǎ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過(guò)渡場(chǎng)景，此時(shí)可以只將主干網(wǎng)邊界路由器升級(jí)成雙棧，而核心路由器仍保持IPv4單棧，使用6to4或Softwire Mesh技術(shù)等來(lái)提供IPv6傳輸服務(wù)。

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

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

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

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

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

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

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

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

對(duì)于互聯(lián)網(wǎng)內(nèi)容提供商（ICP）而言需要為Internet提供服務(wù)，并且由于ICP的服務(wù)系統(tǒng)構(gòu)架升級(jí)相對(duì)普通用戶要困難得多，需要對(duì)其進(jìn)行單獨(dú)討論。首先單棧接入網(wǎng)絡(luò)應(yīng)當(dā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ù)來(lái)為IPvY Internet提供服務(wù)。

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

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

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

參考文獻(xiàn)

[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過(guò)渡場(chǎng)景分析 [R]. 中國(guó)通信行業(yè)研究報(bào)告， 2012B7. 2012.

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

作者簡(jiǎn)介

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

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

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