基于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é)議的互聯(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ī)模的急劇擴(kuò)張突顯了IPv4 的一系列嚴(yán)重問題，包括地址資源緊張、路由可擴(kuò)展性不足、網(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)路由、可擴(kuò)展性、狀態(tài)維護(hù)等問題。此外，由于大多數(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ò)可擴(kuò)展性，即IPv4、IPv6 網(wǎng)絡(luò)各自路由的獨立性和可擴(kuò)展性，這是在過渡時期在對既有IPv4 網(wǎng)絡(luò)進(jìn)行最小化改動的情況下平滑實現(xiàn)IPv6 過渡的重要保證。
（3）對上層移動應(yīng)用呈現(xiàn)透明性，這是在IPv6 過渡時期維護(hù)既有的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）維護(hù)雙棧，CE 為與接入網(wǎng)不同地址簇的分組建立隧道發(fā)往BR，這樣CE 與BR間使用隧道為與接入網(wǎng)地址簇異構(gòu)的分組提供透明傳輸[8]。
圖1全網(wǎng)IPv6 隧道過渡框架示意圖
全網(wǎng)隧道過渡路線是一個IPv4到IPv6 over IPv4 到雙棧到IPv4 overIPv6 到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）進(jìn)行路由信息交互。主干網(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）進(jìn)行4over6 擴(kuò)展[10]。
該擴(kuò)展使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 封裝分組后，對分組進(jìn)行解封裝，并轉(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ò)運營情況進(jìn)行部署，能夠很好地與校園網(wǎng)已有的路由相互隔離開，不對現(xiàn)有的校園網(wǎng)產(chǎn)生影響，同時又能很好地滿足部署的需求。部署與試驗結(jié)果表明，主干網(wǎng)4over6 軟線隧道技術(shù)對主干網(wǎng)改動小，設(shè)備配置簡單，可擴(kuò)展性高，維護(hù)負(fù)擔(dān)小，保護(hù)了原有網(wǎng)絡(luò)設(shè)備投資，能夠支持WEB、
P2P 等各種IPv4 典型應(yīng)用，具有良好可運營性。
圖2主干網(wǎng)4over6軟線隧道技術(shù)在CNGI-CERNET2部署示意
3 IPv6 接入網(wǎng)4over6 軟線隧道技術(shù)原理
接入網(wǎng)的主要任務(wù)是為用戶邊緣設(shè)備提供接入主干網(wǎng)或互聯(lián)網(wǎng)的服務(wù)。為達(dá)到這一目的，在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 維護(hù)，稱為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。
圖3 接入網(wǎng)4over6 軟線隧道體系結(jié)構(gòu)
控制層面上，IPv6 網(wǎng)絡(luò)中的4over6 CE 通過自適應(yīng)異構(gòu)動態(tài)接入機制[13]接入IPv4 互聯(lián)網(wǎng)。
為4over6 CE 分配IPv4 地址的DHCP
服務(wù)器由ISP 維護(hù)，既可與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進(jìn)行了擴(kuò)展，采用了基于IPv6 傳輸?shù)腄HCPv4 over IPv6 擴(kuò)展機制來進(jìn)行IPv4 地址分配。DHCPv4 over IPv6 機制包含兩種場景，如圖4 所示。圖4（a）所示為DHCPv4 客戶端通過客戶中繼代理（CRA）與IPv6 擴(kuò)展DHCP 服務(wù)器（TSV）進(jìn)行通信，而圖4（b）所示為DHCPv4 客戶端通過CRA 和IPv6 傳輸中繼代理（TRA），與傳統(tǒng)DHCP 服務(wù)器進(jìn)行通信。
圖4 DHCPv4 over IPv6 機制應(yīng)用場景
CRA 與DHCPv4 客戶端處于同一主機中，負(fù)責(zé)對DHCPv4 客戶端與TSV/TRA 之間的DHCPv4 信息進(jìn)行中繼。CRA 與DHCPv4 客戶端通過IPv4進(jìn)行通信，與TSV/TRA 則通過UDPv6報文進(jìn)行通信。TRA 部署在IPv6 網(wǎng)絡(luò)與IPv4 網(wǎng)絡(luò)之間，負(fù)責(zé)對CRA 與純IPv4 的傳統(tǒng)DHCPv4 服務(wù)器之間的DHCPv4 消息進(jìn)行中繼。TSV 是支持IPv6 報文傳輸?shù)腄HCP 服務(wù)器。它部署在IPv6 網(wǎng)絡(luò)中，與CRA 或TRA 進(jìn)行IPv6 報文承載的DHCP 數(shù)據(jù)傳輸，從而完成與DHCP 客戶端的交互，并為客戶端主機分配IPv4 地址。通過該機制，DHCP 客戶端無需進(jìn)行任何改動，即能獲取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 報文進(jìn)行IPv6 報文頭的封裝，原本的IPv4 報文成為了IPv6 報文的負(fù)載。之后4over6 CE 將該報文發(fā)送至IPv6 網(wǎng)絡(luò)，報文經(jīng)由IPv6 網(wǎng)絡(luò)被遞交給4over6 BR。4over6BR 在收到該報文后，首先對該IPv6報文進(jìn)行解封裝，將其還原為IPv4 報文，之后4over6 BR 將報文交由IPv4 網(wǎng)絡(luò)進(jìn)行后續(xù)轉(zhuǎn)發(fā)過程。
當(dāng)4over6 BR 需要向4over6 CE 發(fā)起通信時，4over6 BR 首先檢查在本機維護(hù)的4over6 CE 端IPv6 地址與IPv4地址映射表，通過匹配IPv4 報文目的地址與映射記錄，找出對應(yīng)的IPv6 地址作為IPv6 頭的目的地址，并以4over6 BR 本機的IPv6 地址為源地址，對IPv4 報文進(jìn)行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)維護(hù)來記錄4over6 CE 的IPv4-IPv6 地址對應(yīng)信息。4over6 BR并不關(guān)心4over6 CE 建立的會話數(shù)，僅維護(hù)4over6 CE 的IPv6 地址與IPv4 地址的映射，因此這是一個每用戶有狀態(tài)、每流無狀態(tài)映射。用戶級狀態(tài)維護(hù)機制的運用極大地減少了4over6BR 的運維開銷，減輕了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 上開源，開源項目將為擴(kuò)大技術(shù)方案影響、吸引同行共同參與完善技術(shù)方案做出重要貢獻(xiàn)。
目前接入網(wǎng)4over6 軟線隧道過渡方案及相關(guān)技術(shù)已在IETF softwire 及dhc 工作組形成了多項標(biāo)準(zhǔn)草案，引起了業(yè)界的廣泛關(guān)注。在推動技術(shù)方案標(biāo)準(zhǔn)化過程中，清華大學(xué)也帶動中國多家設(shè)備廠商進(jìn)行了4over6 軟線隧道技術(shù)的設(shè)備實現(xiàn)。基于多種軟硬件平臺的技術(shù)實現(xiàn)形成了接入網(wǎng)4over6 軟線隧道技術(shù)原型系統(tǒng)體系。在此基礎(chǔ)上，清華大學(xué)在IPv6 校園網(wǎng)進(jìn)行了接入網(wǎng)4over6 軟線隧道技術(shù)試驗部署，如圖5 所示。此外，中國電信在湖南省網(wǎng)部署了面向
寬帶網(wǎng)的IPv4 與IPv6 雙棧環(huán)境，完成了輕量級4over6 軟線隧道技術(shù)LAFT6 的現(xiàn)網(wǎng)試驗部署[14]。各項實驗與試驗部署結(jié)果顯示，接入網(wǎng)4over6 軟線隧道技術(shù)實現(xiàn)簡單，易于部署，運維開銷小，擴(kuò)展性強，能對既有IPv4 應(yīng)用和服務(wù)提供良好支持。
圖5 清華大學(xué)IPv6 校園網(wǎng)試驗部署
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)。基于技術(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 過渡提供了重要解決方案。
參考文獻(xiàn)
[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.
