基于IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4" title="IPv4">IPv4 協(xié)議的互聯網經過20 多年的飛速發(fā)展，在全球范圍內已經取得了巨大的成功。但是，隨著互聯網規(guī)模的持續(xù)增長和新需求、新業(yè)務的發(fā)展，基于IPv4 協(xié)議的網絡環(huán)境已經難以應對，網絡規(guī)模的急劇擴張突顯了IPv4 的一系列嚴重問題，包括地址資源緊張、路由可擴展性不足、網絡地址轉換（NAT）技術[1] 帶來的端到端特性破壞等。
IPv6 協(xié)議[2] 是下一代互聯網中替代IPv4 的網絡基礎協(xié)議。由于IPv6與IPv4 并不兼容，互聯網在從IPv4 向IPv6 過渡過程中面臨著異構路由、可擴展性、狀態(tài)維護等問題。此外，由于大多數網絡資源、服務和應用仍基于IPv4 實現，終端用戶對IPv4 仍然存在依賴性，因特網業(yè)務提供商（ISP）對于IPv6 升級存在一定惰性，以及網絡設備尤其是
接入網設備對IPv6 的支持不足等因素，可以預見IPv4 與IPv6 將在較長一段時期中共存。而在二者共存期間，如何較快較好地實現全網向IPv6 過渡、尤其是接入網的過渡，已經成為制約下一代互聯網發(fā)展的關鍵。
針對IPv6 過渡問題，目前國際上已提出了許多過渡技術方案[3]，這些方案按技術思想分類，大體上可分為隧道技術和翻譯技術[4-5]。本文從隧道過渡思想出發(fā)，提出了面向全網的IPv6 隧道過渡框架體系，以及主干網和接入網過渡各自適用的4over6 軟線隧道技術。目前4over6 軟線隧道過渡方案及相關技術已在國際互聯網標準化組織IETF 形成了RFC4925、RFC5565 及RFC5747 等3 項國際標準，并在中國通信標準化協(xié)會形成了2 項中國通信行業(yè)標準。
1 全網IPv6 隧道過渡框架與策略
面向全網的IPv6 過渡技術方案需要滿足以下需求[6]：
（1）保持端到端特性，這是實現終端節(jié)點與互聯網間無障礙雙向互聯互通需要滿足的基本要求。
（2）保持異構網絡可擴展性，即IPv4、IPv6 網絡各自路由的獨立性和可擴展性，這是在過渡時期在對既有IPv4 網絡進行最小化改動的情況下平滑實現IPv6 過渡的重要保證。
（3）對上層移動應用呈現透明性，這是在IPv6 過渡時期維護既有的IPv4 應用，保證用戶良好網絡體驗的關鍵保障。
全網IPv6 隧道過渡問題[7]按照網絡層次不同可劃分為主干網IPv6 過渡及接入網IPv6 過渡，其隧道過渡框架如圖1 所示。主干網向上連接ISP網絡，同級連接其他的主干網，向下連接接入網。接入網向上連接主干網，向下為各種不同類型的用戶提供接入。在接入網與主干網相鄰一側有若干邊界
路由器（BR）與邊緣路由器（PE）相連接。主干網隧道過渡要求PE 升級為雙棧，PE 之間使用隧道為與主干網地址簇異構的分組提供透明傳輸。接入網隧道過渡要求BR以及用戶側邊緣設備（CE）維護雙棧，CE 為與接入網不同地址簇的分組建立隧道發(fā)往BR，這樣CE 與BR間使用隧道為與接入網地址簇異構的分組提供透明傳輸[8]。
圖1全網IPv6 隧道過渡框架示意圖
全網隧道過渡路線是一個IPv4到IPv6 over IPv4 到雙棧到IPv4 overIPv6 到IPv6 的過程。過渡初期，一些IPv6 接入網孤島出現，這些網絡需要互訪以及訪問IPv6 互聯網。此時由于IPv4 傳輸仍是主流，大量主干網核心路由器（P）仍是IPv4 單棧，將這些P 路由器都升級為雙棧比較困難。
因此應優(yōu)先將少數PE 路由器升級為雙棧，并通過6over4 隧道為IPv6 孤島提供跨越IPv4 傳輸服務。主干網P路由器會在運行IPv4 基礎上啟動IPv6 協(xié)議棧，即升級為雙棧。隨著雙棧P 路由器規(guī)模增大，相應運維開銷也逐漸增大，而IPv4 傳輸需求越來越少，因此P 路由器會逐漸關閉IPv4 協(xié)議棧而只運行IPv6 單棧；PE 路由器則仍維持雙棧，通過4over6 隧道為IPv4 網絡提供IPv6 網絡跨越傳輸服務；最終IPv6 在全網中完全部署，網絡全面實現向IPv6 的過渡。
2 IPv6 主干網4over6 軟線隧道技術原理與應用
主干網邊緣處的PE 與上級、接入網、同級主干網之間運行外部邊界
網關協(xié)議（EBGP），互相傳遞域間路由信息，而主干網內側的骨干路由器（PR）間則通過內部邊界網關協(xié)議（IBGP）進行路由信息交互。主干網的主要任務是提供IPv4 和IPv6 的接入和傳輸服務，在IPv6 單棧主干網中需要部署實現主干網4over6 軟線隧道技術[9]。
4over6 軟線隧道技術通過自動隧道機制來建立4over6 軟線隧道。
4over6 軟線隧道技術對IPv6 主干網的核心路由協(xié)議—— 多協(xié)議邊界網關協(xié)議（MP-BGP）進行4over6 擴展[10]。
該擴展使MP-BGP 報文攜帶IPv4 目的網絡的信息和隧道端點信息并發(fā)送到IPv6 主干網的另一端，通過IPv4/IPv6 路由異構隔離混傳使PE 間能建立無狀態(tài)的4over6 軟線隧道。PE 與CE 之間可以通過域內或域間IPv4 路由協(xié)議來交互IPv4 路由，也可以由CE 配置缺省路由到PE。PE 需要完成分組的封裝、解封裝及轉發(fā)處理。
在入口PE 通過IPv4 路由找到合適的出口PE 后，入口PE 需要采用IPv4-in-IPv6 封裝機制來封裝并轉發(fā)原始IPv4 分組。出口PE 在IPv6 主干網側收到IPv4-in-IPv6 封裝分組后，對分組進行解封裝，并轉發(fā)到相應的IPv4 目的網絡。
目前主干網4over6 軟線隧道技術已在IETF 形成了2 項國際標準RFC5565 和RFC5747，并已在當前世界上最大的IPv6 單棧主干網——CNGI-CERNET2 上完成了部署，形成了有百所高校校園網參加的4over6軟線隧道過渡試商用系統(tǒng)。主干網4over6 軟線隧道技術在CNGI-CERNET2 部署如圖2 所示。主干網4over6 軟線隧道技術結合各大高校的實際網絡運營情況進行部署，能夠很好地與校園網已有的路由相互隔離開，不對現有的校園網產生影響，同時又能很好地滿足部署的需求。部署與試驗結果表明，主干網4over6 軟線隧道技術對主干網改動小，設備配置簡單，可擴展性高，維護負擔小，保護了原有網絡設備投資，能夠支持WEB、
P2P 等各種IPv4 典型應用，具有良好可運營性。
圖2主干網4over6軟線隧道技術在CNGI-CERNET2部署示意
3 IPv6 接入網4over6 軟線隧道技術原理
接入網的主要任務是為用戶邊緣設備提供接入主干網或互聯網的服務。為達到這一目的，在IPv6 單棧主干網中需要部署實現接入網4over6軟線隧道技術[11-12]。
接入網4over6 軟線隧道體系結構如圖3 所示。作為4over6 隧道發(fā)起點的CE 既可以是終端主機，也可以是用戶駐地設備（CPE），如家庭網關等，統(tǒng)稱為4over6 CE。作為4over6 軟線隧道匯聚點的BR 由ISP 維護，稱為4over6 BR，部署在ISP IPv6 網絡（IPv6接入網）與IPv4 互聯網（或主干網）交界處，所有出入ISP 網絡的IPv4 報文均要經過4over6 BR。
圖3 接入網4over6 軟線隧道體系結構
控制層面上，IPv6 網絡中的4over6 CE 通過自適應異構動態(tài)接入機制[13]接入IPv4 互聯網。
為4over6 CE 分配IPv4 地址的DHCP
服務器由ISP 維護，既可與4over6 BR 聯合部署，也可作為獨立DHCPv4 服務器與4over6 BR 部署在同一IPv4 網絡中。由于4over6 CE 與4over6 BR 間通過純IPv6 接入網連接，傳統(tǒng)的動態(tài)主機配置協(xié)議（DHCP）不能在IPv6 網絡中正常運行，因此接入網4over6 軟線隧道技術對傳統(tǒng)DHCP進行了擴展，采用了基于IPv6 傳輸的DHCPv4 over IPv6 擴展機制來進行IPv4 地址分配。DHCPv4 over IPv6 機制包含兩種場景，如圖4 所示。圖4（a）所示為DHCPv4 客戶端通過客戶中繼代理（CRA）與IPv6 擴展DHCP 服務器（TSV）進行通信，而圖4（b）所示為DHCPv4 客戶端通過CRA 和IPv6 傳輸中繼代理（TRA），與傳統(tǒng)DHCP 服務器進行通信。
圖4 DHCPv4 over IPv6 機制應用場景
CRA 與DHCPv4 客戶端處于同一主機中，負責對DHCPv4 客戶端與TSV/TRA 之間的DHCPv4 信息進行中繼。CRA 與DHCPv4 客戶端通過IPv4進行通信，與TSV/TRA 則通過UDPv6報文進行通信。TRA 部署在IPv6 網絡與IPv4 網絡之間，負責對CRA 與純IPv4 的傳統(tǒng)DHCPv4 服務器之間的DHCPv4 消息進行中繼。TSV 是支持IPv6 報文傳輸的DHCP 服務器。它部署在IPv6 網絡中，與CRA 或TRA 進行IPv6 報文承載的DHCP 數據傳輸，從而完成與DHCP 客戶端的交互，并為客戶端主機分配IPv4 地址。通過該機制，DHCP 客戶端無需進行任何改動，即能獲取TSV 分配的IPv4 地址及其他資源。
數據層面上，在4over6 軟線隧道兩端，4over6 CE 與4over6 BR 分別完成IPv4-in-IPv6 的封裝和解封裝工作。
當4over6 CE 需要向4over6 BR 發(fā)起通信時，4over6 CE 首先根據本機IPv6 地址以及事先得知的4over6 BR端IPv6 地址，對IPv4 報文進行IPv6 報文頭的封裝，原本的IPv4 報文成為了IPv6 報文的負載。之后4over6 CE 將該報文發(fā)送至IPv6 網絡，報文經由IPv6 網絡被遞交給4over6 BR。4over6BR 在收到該報文后，首先對該IPv6報文進行解封裝，將其還原為IPv4 報文，之后4over6 BR 將報文交由IPv4 網絡進行后續(xù)轉發(fā)過程。
當4over6 BR 需要向4over6 CE 發(fā)起通信時，4over6 BR 首先檢查在本機維護的4over6 CE 端IPv6 地址與IPv4地址映射表，通過匹配IPv4 報文目的地址與映射記錄，找出對應的IPv6 地址作為IPv6 頭的目的地址，并以4over6 BR 本機的IPv6 地址為源地址，對IPv4 報文進行IPv6 報文頭的封裝，IPv4 頭及以內的內容成為了IPv6 報文的負載。之后4over6 BR 將該報文發(fā)送至IPv6 網絡，報文經由IPv6 網絡被遞交給4over6 CE。4over6 CE 在收到該報文后，解封裝其IPv6 報文頭，將報文還原為IPv4 報文，并轉交給上層應用。
4over6 BR 通過輕量級的用戶級狀態(tài)維護來記錄4over6 CE 的IPv4-IPv6 地址對應信息。4over6 BR并不關心4over6 CE 建立的會話數，僅維護4over6 CE 的IPv6 地址與IPv4 地址的映射，因此這是一個每用戶有狀態(tài)、每流無狀態(tài)映射。用戶級狀態(tài)維護機制的運用極大地減少了4over6BR 的運維開銷，減輕了ISP 網絡負擔，提升了終端用戶的網絡體驗。
4 IPv6 接入網4over6 軟線隧道技術系統(tǒng)研制與部署試驗
清華大學完成了基于Linux、Windows7 及Android 系統(tǒng)的4over6 軟線隧道軟件系統(tǒng)實現。軟件系統(tǒng)源代碼于2012 年在開源社區(qū)Github 上開源，開源項目將為擴大技術方案影響、吸引同行共同參與完善技術方案做出重要貢獻。
目前接入網4over6 軟線隧道過渡方案及相關技術已在IETF softwire 及dhc 工作組形成了多項標準草案，引起了業(yè)界的廣泛關注。在推動技術方案標準化過程中，清華大學也帶動中國多家設備廠商進行了4over6 軟線隧道技術的設備實現?；诙喾N軟硬件平臺的技術實現形成了接入網4over6 軟線隧道技術原型系統(tǒng)體系。在此基礎上，清華大學在IPv6 校園網進行了接入網4over6 軟線隧道技術試驗部署，如圖5 所示。此外，中國電信在湖南省網部署了面向
寬帶網的IPv4 與IPv6 雙棧環(huán)境，完成了輕量級4over6 軟線隧道技術LAFT6 的現網試驗部署[14]。各項實驗與試驗部署結果顯示，接入網4over6 軟線隧道技術實現簡單，易于部署，運維開銷小，擴展性強，能對既有IPv4 應用和服務提供良好支持。
圖5 清華大學IPv6 校園網試驗部署
5 結束語
本文針對下一代互聯網IPv6 過渡關鍵技術問題，從隧道過渡角度展開研究，提出了面向全網IPv6 過渡的4over6 軟線隧道技術方案。技術方案針對全網IPv6 過渡需求，提出了主干網及接入網分別適用的4over6 軟線隧道技術，形成了統(tǒng)一的隧道過渡技術體系，通過主干網異構路由隔離混傳、接入網自適應異構動態(tài)接入以及透明化自動隧道等機制實現全網IPv6 平滑過渡。目前4over6 軟線隧道技術方案已形成3 項IETF 國際標準及2 項國家通信行業(yè)標準。基于技術方案的研究和標準化，4over6 軟線隧道技術已完成多項系統(tǒng)研制、應用與部署。各項應用、實驗與部署結果表明，4over6 軟線隧道技術具有實現簡單、易于配置與部署、運維開銷小、對IPv4 應用及服務能提供良好支持等優(yōu)勢，為推動下一代互聯網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.
