崔勇,陳煜馳

摘要：針對下一代互聯(lián)網(wǎng)IPv6過渡關(guān)鍵技術(shù)問題，從隧道過渡角度展開研究，提出了面向全網(wǎng)IPv6過渡的4over6軟線隧道技術(shù)方案。技術(shù)方案針對全網(wǎng)IPv6過渡需求，設(shè)計了主干網(wǎng)及接入網(wǎng)分別適用的4over6軟線隧道技術(shù)，形成了統(tǒng)一的隧道過渡技術(shù)體系，通過主干網(wǎng)異構(gòu)路由隔離混傳、接入網(wǎng)自適應(yīng)異構(gòu)動態(tài)接入以及透明化自動隧道等機制實現(xiàn)下一代互聯(lián)網(wǎng)IPv6平滑過渡。

關(guān)鍵詞： 下一代互聯(lián)網(wǎng)；軟線；隧道；IPv6過渡

Abstract： This paper focuses on issues with key techniques in IPv6 transition for next-generation Internet. In this paper， we propose a 4over6 softwire tunneling mechanism. We propose different 4over6 softwire tunneling technologies for the backbone and access networks. These technologies are used to create a unified tunneling transition system and satisfy the requirements for IPv6 transition across the whole network. Smooth IPv6 transition can be achieved using mechanisms such as heterogeneous routing separation and transport in the backbone， dynamic self-adaptation and heterogeneous access in the access network， and transparent automatic tunneling.

Key words： next-generation Internet； softwire； tunneling； IPv6 transition

基于IPv4協(xié)議的互聯(lián)網(wǎng)經(jīng)過20多年的飛速發(fā)展，在全球范圍內(nèi)已經(jīng)取得了巨大的成功。但是，隨著互聯(lián)網(wǎng)規(guī)模的持續(xù)增長和新需求、新業(yè)務(wù)的發(fā)展，基于IPv4協(xié)議的網(wǎng)絡(luò)環(huán)境已經(jīng)難以應(yīng)對，網(wǎng)絡(luò)規(guī)模的急劇擴張突顯了IPv4的一系列嚴(yán)重問題，包括地址資源緊張、路由可擴展性不足、網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）技術(shù)[1]帶來的端到端特性破壞等。

IPv6協(xié)議[2]是下一代互聯(lián)網(wǎng)中替代IPv4的網(wǎng)絡(luò)基礎(chǔ)協(xié)議。由于IPv6與IPv4并不兼容，互聯(lián)網(wǎng)在從IPv4向IPv6過渡過程中面臨著異構(gòu)路由、可擴展性、狀態(tài)維護等問題。此外，由于大多數(shù)網(wǎng)絡(luò)資源、服務(wù)和應(yīng)用仍基于IPv4實現(xiàn)，終端用戶對IPv4仍然存在依賴性，因特網(wǎng)業(yè)務(wù)提供商（ISP）對于IPv6升級存在一定惰性，以及網(wǎng)絡(luò)設(shè)備尤其是接入網(wǎng)設(shè)備對IPv6的支持不足等因素，可以預(yù)見IPv4與IPv6將在較長一段時期中共存。而在二者共存期間，如何較快較好地實現(xiàn)全網(wǎng)向IPv6過渡、尤其是接入網(wǎng)的過渡，已經(jīng)成為制約下一代互聯(lián)網(wǎng)發(fā)展的關(guān)鍵。

針對IPv6過渡問題，目前國際上已提出了許多過渡技術(shù)方案[3]，這些方案按技術(shù)思想分類，大體上可分為隧道技術(shù)和翻譯技術(shù)[4-5]。本文從隧道過渡思想出發(fā)，提出了面向全網(wǎng)的IPv6隧道過渡框架體系，以及主干網(wǎng)和接入網(wǎng)過渡各自適用的4over6軟線隧道技術(shù)。目前4over6軟線隧道過渡方案及相關(guān)技術(shù)已在國際互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織IETF形成了RFC4925、RFC5565及RFC5747等3項國際標(biāo)準(zhǔn)，并在中國通信標(biāo)準(zhǔn)化協(xié)會形成了2項中國通信行業(yè)標(biāo)準(zhǔn)。

1 全網(wǎng)IPv6隧道過渡框架

與策略

面向全網(wǎng)的IPv6過渡技術(shù)方案需要滿足以下需求[6]：

（1）保持端到端特性，這是實現(xiàn)終端節(jié)點與互聯(lián)網(wǎng)間無障礙雙向互聯(lián)互通需要滿足的基本要求。

（2）保持異構(gòu)網(wǎng)絡(luò)可擴展性，即IPv4、IPv6網(wǎng)絡(luò)各自路由的獨立性和可擴展性，這是在過渡時期在對既有IPv4網(wǎng)絡(luò)進行最小化改動的情況下平滑實現(xiàn)IPv6過渡的重要保證。

（3）對上層移動應(yīng)用呈現(xiàn)透明性，這是在IPv6過渡時期維護既有的IPv4應(yīng)用，保證用戶良好網(wǎng)絡(luò)體驗的關(guān)鍵保障。

全網(wǎng)IPv6隧道過渡問題[7]按照網(wǎng)絡(luò)層次不同可劃分為主干網(wǎng)IPv6過渡及接入網(wǎng)IPv6過渡，其隧道過渡框架如圖1所示。主干網(wǎng)向上連接ISP網(wǎng)絡(luò)，同級連接其他的主干網(wǎng)，向下連接接入網(wǎng)。接入網(wǎng)向上連接主干網(wǎng)，向下為各種不同類型的用戶提供接入。在接入網(wǎng)與主干網(wǎng)相鄰一側(cè)有若干邊界路由器（BR）與邊緣路由器（PE）相連接。主干網(wǎng)隧道過渡要求PE升級為雙棧，PE之間使用隧道為與主干網(wǎng)地址簇異構(gòu)的分組提供透明傳輸。接入網(wǎng)隧道過渡要求BR以及用戶側(cè)邊緣設(shè)備（CE）維護雙棧，CE為與接入網(wǎng)不同地址簇的分組建立隧道發(fā)往BR，這樣CE與BR間使用隧道為與接入網(wǎng)地址簇異構(gòu)的分組提供透明傳輸[8]。

全網(wǎng)隧道過渡路線是一個IPv4到IPv6 over IPv4到雙棧到IPv4 over IPv6到IPv6的過程。過渡初期，一些IPv6接入網(wǎng)孤島出現(xiàn)，這些網(wǎng)絡(luò)需要互訪以及訪問IPv6互聯(lián)網(wǎng)。此時由于IPv4傳輸仍是主流，大量主干網(wǎng)核心路由器（P）仍是IPv4單棧，將這些P路由器都升級為雙棧比較困難。因此應(yīng)優(yōu)先將少數(shù)PE路由器升級為雙棧，并通過6over4隧道為IPv6孤島提供跨越IPv4傳輸服務(wù)。主干網(wǎng)P路由器會在運行IPv4基礎(chǔ)上啟動IPv6協(xié)議棧，即升級為雙棧。隨著雙棧P路由器規(guī)模增大，相應(yīng)運維開銷也逐漸增大，而IPv4傳輸需求越來越少，因此P路由器會逐漸關(guān)閉IPv4協(xié)議棧而只運行IPv6單棧；PE路由器則仍維持雙棧，通過4over6隧道為IPv4網(wǎng)絡(luò)提供IPv6網(wǎng)絡(luò)跨越傳輸服務(wù)；最終IPv6在全網(wǎng)中完全部署，網(wǎng)絡(luò)全面實現(xiàn)向IPv6的過渡。

2 IPv6主干網(wǎng)4over6軟線

隧道技術(shù)原理與應(yīng)用

主干網(wǎng)邊緣處的PE與上級、接入網(wǎng)、同級主干網(wǎng)之間運行外部邊界網(wǎng)關(guān)協(xié)議（EBGP），互相傳遞域間路由信息，而主干網(wǎng)內(nèi)側(cè)的骨干路由器（PR）間則通過內(nèi)部邊界網(wǎng)關(guān)協(xié)議（IBGP）進行路由信息交互。主干網(wǎng)的主要任務(wù)是提供IPv4和IPv6的接入和傳輸服務(wù)，在IPv6單棧主干網(wǎng)中需要部署實現(xiàn)主干網(wǎng)4over6軟線隧道技術(shù)[9]。

4over6軟線隧道技術(shù)通過自動隧道機制來建立4over6軟線隧道。4over6軟線隧道技術(shù)對IPv6主干網(wǎng)的核心路由協(xié)議——多協(xié)議邊界網(wǎng)關(guān)協(xié)議（MP-BGP）進行4over6擴展[10]。該擴展使MP-BGP報文攜帶IPv4目的網(wǎng)絡(luò)的信息和隧道端點信息并發(fā)送到IPv6主干網(wǎng)的另一端，通過IPv4/IPv6路由異構(gòu)隔離混傳使PE間能建立無狀態(tài)的4over6軟線隧道。PE與CE之間可以通過域內(nèi)或域間IPv4路由協(xié)議來交互IPv4路由，也可以由CE配置缺省路由到PE。PE需要完成分組的封裝、解封裝及轉(zhuǎn)發(fā)處理。在入口PE通過IPv4路由找到合適的出口PE后，入口PE需要采用IPv4-in-IPv6封裝機制來封裝并轉(zhuǎn)發(fā)原始IPv4分組。出口PE在IPv6主干網(wǎng)側(cè)收到IPv4-in-IPv6封裝分組后，對分組進行解封裝，并轉(zhuǎn)發(fā)到相應(yīng)的IPv4目的網(wǎng)絡(luò)。

目前主干網(wǎng)4over6軟線隧道技術(shù)已在IETF形成了2項國際標(biāo)準(zhǔn)RFC5565和RFC5747，并已在當(dāng)前世界上最大的IPv6單棧主干網(wǎng)——CNGI-CERNET2上完成了部署，形成了有百所高校校園網(wǎng)參加的4over6軟線隧道過渡試商用系統(tǒng)。主干網(wǎng)4over6軟線隧道技術(shù)在CNGI-CERNET2部署如圖2所示。主干網(wǎng)4over6軟線隧道技術(shù)結(jié)合各大高校的實際網(wǎng)絡(luò)運營情況進行部署，能夠很好地與校園網(wǎng)已有的路由相互隔離開，不對現(xiàn)有的校園網(wǎng)產(chǎn)生影響，同時又能很好地滿足部署的需求。部署與試驗結(jié)果表明，主干網(wǎng)4over6軟線隧道技術(shù)對主干網(wǎng)改動小，設(shè)備配置簡單，可擴展性高，維護負(fù)擔(dān)小，保護了原有網(wǎng)絡(luò)設(shè)備投資，能夠支持WEB、P2P等各種IPv4典型應(yīng)用，具有良好可運營性。

3 IPv6接入網(wǎng)4over6軟線

隧道技術(shù)原理

接入網(wǎng)的主要任務(wù)是為用戶邊緣設(shè)備提供接入主干網(wǎng)或互聯(lián)網(wǎng)的服務(wù)。為達到這一目的，在IPv6單棧主干網(wǎng)中需要部署實現(xiàn)接入網(wǎng)4over6軟線隧道技術(shù)[11-12]。

接入網(wǎng)4over6軟線隧道體系結(jié)構(gòu)如圖3所示。作為4over6隧道發(fā)起點的CE既可以是終端主機，也可以是用戶駐地設(shè)備（CPE），如家庭網(wǎng)關(guān)等，統(tǒng)稱為4over6 CE。作為4over6軟線隧道匯聚點的BR由ISP維護，稱為4over6 BR，部署在ISP IPv6網(wǎng)絡(luò)（IPv6接入網(wǎng)）與IPv4互聯(lián)網(wǎng)（或主干網(wǎng)）交界處，所有出入ISP網(wǎng)絡(luò)的IPv4報文均要經(jīng)過4over6 BR。

控制層面上，IPv6網(wǎng)絡(luò)中的4over6 CE通過自適應(yīng)異構(gòu)動態(tài)接入機制[13]接入IPv4互聯(lián)網(wǎng)。

為4over6 CE分配IPv4地址的DHCP服務(wù)器由ISP維護，既可與4over6 BR聯(lián)合部署，也可作為獨立DHCPv4服務(wù)器與4over6 BR部署在同一IPv4網(wǎng)絡(luò)中。由于4over6 CE與4over6 BR間通過純IPv6接入網(wǎng)連接，傳統(tǒng)的動態(tài)主機配置協(xié)議（DHCP）不能在IPv6網(wǎng)絡(luò)中正常運行，因此接入網(wǎng)4over6軟線隧道技術(shù)對傳統(tǒng)DHCP進行了擴展，采用了基于IPv6傳輸?shù)腄HCPv4 over IPv6擴展機制來進行IPv4地址分配。DHCPv4 over IPv6機制包含兩種場景，如圖4所示。圖4（a）所示為DHCPv4客戶端通過客戶中繼代理（CRA）與IPv6擴展DHCP服務(wù)器（TSV）進行通信，而圖4（b）所示為DHCPv4客戶端通過CRA和IPv6傳輸中繼代理（TRA），與傳統(tǒng)DHCP服務(wù)器進行通信。

CRA與DHCPv4客戶端處于同一主機中，負(fù)責(zé)對DHCPv4客戶端與TSV/TRA之間的DHCPv4信息進行中繼。CRA與DHCPv4客戶端通過IPv4進行通信，與TSV/TRA則通過UDPv6報文進行通信。TRA部署在IPv6網(wǎng)絡(luò)與IPv4網(wǎng)絡(luò)之間，負(fù)責(zé)對CRA與純IPv4的傳統(tǒng)DHCPv4服務(wù)器之間的DHCPv4消息進行中繼。TSV是支持IPv6報文傳輸?shù)腄HCP服務(wù)器。它部署在IPv6網(wǎng)絡(luò)中，與CRA或TRA進行IPv6報文承載的DHCP數(shù)據(jù)傳輸，從而完成與DHCP客戶端的交互，并為客戶端主機分配IPv4地址。通過該機制，DHCP客戶端無需進行任何改動，即能獲取TSV分配的IPv4地址及其他資源。

數(shù)據(jù)層面上，在4over6軟線隧道兩端，4over6 CE與4over6 BR分別完成IPv4-in-IPv6的封裝和解封裝工作。

當(dāng)4over6 CE需要向4over6 BR發(fā)起通信時，4over6 CE首先根據(jù)本機IPv6地址以及事先得知的4over6 BR端IPv6地址，對IPv4報文進行IPv6報文頭的封裝，原本的IPv4報文成為了IPv6報文的負(fù)載。之后4over6 CE將該報文發(fā)送至IPv6網(wǎng)絡(luò)，報文經(jīng)由IPv6網(wǎng)絡(luò)被遞交給4over6 BR。4over6 BR在收到該報文后，首先對該IPv6報文進行解封裝，將其還原為IPv4報文，之后4over6 BR將報文交由IPv4網(wǎng)絡(luò)進行后續(xù)轉(zhuǎn)發(fā)過程。

當(dāng)4over6 BR需要向4over6 CE發(fā)起通信時，4over6 BR首先檢查在本機維護的4over6 CE端IPv6地址與IPv4地址映射表，通過匹配IPv4報文目的地址與映射記錄，找出對應(yīng)的IPv6地址作為IPv6頭的目的地址，并以4over6 BR本機的IPv6地址為源地址，對IPv4報文進行IPv6報文頭的封裝，IPv4頭及以內(nèi)的內(nèi)容成為了IPv6報文的負(fù)載。之后4over6 BR將該報文發(fā)送至IPv6網(wǎng)絡(luò)，報文經(jīng)由IPv6網(wǎng)絡(luò)被遞交給4over6 CE。4over6 CE在收到該報文后，解封裝其IPv6報文頭，將報文還原為IPv4報文，并轉(zhuǎn)交給上層應(yīng)用。

4over6 BR通過輕量級的用戶級狀態(tài)維護來記錄4over6 CE的IPv4-IPv6地址對應(yīng)信息。4over6 BR并不關(guān)心4over6 CE建立的會話數(shù)，僅維護4over6 CE的IPv6地址與IPv4地址的映射，因此這是一個每用戶有狀態(tài)、每流無狀態(tài)映射。用戶級狀態(tài)維護機制的運用極大地減少了4over6 BR的運維開銷，減輕了ISP網(wǎng)絡(luò)負(fù)擔(dān)，提升了終端用戶的網(wǎng)絡(luò)體驗。

4 IPv6接入網(wǎng)4over6軟線

隧道技術(shù)系統(tǒng)研制與

部署試驗

清華大學(xué)完成了基于Linux、Windows7及Android系統(tǒng)的4over6軟線隧道軟件系統(tǒng)實現(xiàn)。軟件系統(tǒng)源代碼于2012年在開源社區(qū)Github上開源，開源項目將為擴大技術(shù)方案影響、吸引同行共同參與完善技術(shù)方案做出重要貢獻。

目前接入網(wǎng)4over6軟線隧道過渡方案及相關(guān)技術(shù)已在IETF softwire及dhc工作組形成了多項標(biāo)準(zhǔn)草案，引起了業(yè)界的廣泛關(guān)注。在推動技術(shù)方案標(biāo)準(zhǔn)化過程中，清華大學(xué)也帶動中國多家設(shè)備廠商進行了4over6軟線隧道技術(shù)的設(shè)備實現(xiàn)?；诙喾N軟硬件平臺的技術(shù)實現(xiàn)形成了接入網(wǎng)4over6軟線隧道技術(shù)原型系統(tǒng)體系。在此基礎(chǔ)上，清華大學(xué)在IPv6校園網(wǎng)進行了接入網(wǎng)4over6軟線隧道技術(shù)試驗部署，如圖5所示。此外，中國電信在湖南省網(wǎng)部署了面向?qū)拵ЬW(wǎng)的IPv4與IPv6雙棧環(huán)境，完成了輕量級4over6軟線隧道技術(shù)LAFT6的現(xiàn)網(wǎng)試驗部署[14]。各項實驗與試驗部署結(jié)果顯示，接入網(wǎng)4over6軟線隧道技術(shù)實現(xiàn)簡單，易于部署，運維開銷小，擴展性強，能對既有IPv4應(yīng)用和服務(wù)提供良好支持。

5 結(jié)束語

本文針對下一代互聯(lián)網(wǎng)IPv6過渡關(guān)鍵技術(shù)問題，從隧道過渡角度展開研究，提出了面向全網(wǎng)IPv6過渡的4over6軟線隧道技術(shù)方案。技術(shù)方案針對全網(wǎng)IPv6過渡需求，提出了主干網(wǎng)及接入網(wǎng)分別適用的4over6軟線隧道技術(shù)，形成了統(tǒng)一的隧道過渡技術(shù)體系，通過主干網(wǎng)異構(gòu)路由隔離混傳、接入網(wǎng)自適應(yīng)異構(gòu)動態(tài)接入以及透明化自動隧道等機制實現(xiàn)全網(wǎng)IPv6平滑過渡。目前4over6軟線隧道技術(shù)方案已形成3項IETF國際標(biāo)準(zhǔn)及2項國家通信行業(yè)標(biāo)準(zhǔn)?；诩夹g(shù)方案的研究和標(biāo)準(zhǔn)化，4over6軟線隧道技術(shù)已完成多項系統(tǒng)研制、應(yīng)用與部署。各項應(yīng)用、實驗與部署結(jié)果表明，4over6軟線隧道技術(shù)具有實現(xiàn)簡單、易于配置與部署、運維開銷小、對IPv4應(yīng)用及服務(wù)能提供良好支持等優(yōu)勢，為推動下一代互聯(lián)網(wǎng)IPv6過渡提供了重要解決方案。

參考文獻

[1] SRISURESH P， EGEVANG K. Traditional IP network address translator （traditional NAT） [S]. RFC3022. 2001.

[2] DEERING S， HINDEN R. Internet protocol version 6 （IPv6） specification [S]. RFC2460. 1998.

[3] 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.

[4] WU P， CUI Y， XU M， et al. Flexible integration of tunneling and translation for IPv6 transition [J]. Springer Networking Science， 2012， 1（1/2/3/4）：23-33.

[5] WU P， CUI Y， XU M， et al. PET： Prefixing， encapsulation and translation for IPv4-IPv6 coexistence [C]//Proceedings of the IEEE Global Telecommunications Conference （GLOBECOM'10）， Dec 6-10，2010， Miami， FL， USA. Piscataway， NJ，USA：IEEE， 2010：5p.

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

[7] LI X， DAWKINS S， WARD D， et al. Softwire problem statement [S]. RFC4925. 2007.

[8] CUI Y， WU P， XU M， et al. 4over6： Network layer virtualization for IPv4/IPv6 coexistence [J]. IEEE Network， 2012， 26（5）：44-48.

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

[10] WU J， CUI Y， LI X， et al. 4over6 transit solution using IP encapsulation and MP-BGP extensions [S]. RFC5747. 2010.

[11] CUI Y， WU J， WU P， et al. Public IPv4 over access IPv6 network [R]. IETF draft. 2012.

[12] CUI Y， SUN Q， BOUCADAIR M， et al. Lightweight 4over6： An extension to the DS-lite architecture [R]. IETF draft. 2012.

[13] CUI Y， WU P， WU J， et al. DHCPv4 over IPv6 transport [R]. IETF draft. 2012.

[14] SUN Q， XIE C， LEE Y， et al. Deployment considerations for lightweight 4over6 [R]. IETF draft. 2012.