劉笑寒,閆雙艦,孫玉勤

摘要：對IPv6-only的網(wǎng)絡(luò)互通技術(shù)從過渡技術(shù)、訪問場景、應(yīng)用需求3方面進行分析，對網(wǎng)絡(luò)構(gòu)建從應(yīng)用、數(shù)據(jù)、狀態(tài)、操作系統(tǒng)4個維度進行探討。對IPv6-only網(wǎng)絡(luò)訪問IPv4 internet這一典型場景，采用NAT64/DNS64翻譯技術(shù)進行系統(tǒng)構(gòu)建，從操作系統(tǒng)、瀏覽器、網(wǎng)絡(luò)應(yīng)用（網(wǎng)頁、即時通信、流媒體）等方面進行測試，并基于測試結(jié)果對IPv6-only的實際部署進行討論。

關(guān)鍵詞： 下一代互聯(lián)網(wǎng)；純IPv6；網(wǎng)絡(luò)互通技術(shù)；NAT64/DNS64翻譯技術(shù)

Abstract： In this paper， we analyze IPv6-only interoperability in terms of transition technologies， visiting scenarios， and application requirements. We also analyze network construction in terms of applications， data， state， and OS. We propose a practical system for accessing IPv4 internet from an IPv6-only network. This system uses NAT64/DNS64 translation technology. We test the OS， web browser， and Internet applications such as web sites， instant messaging， and streaming in this system. We use these test results as the basis for a discussion on the practical deployment of IPv6-only network.

Key words： next-generation Internet； IPv6-only； network interoperability technology； NAT64/DNS64 translation technology

1 IPv6-only網(wǎng)絡(luò)環(huán)境背景

分析

2012年6月的IPv6日，世界范圍內(nèi)全面啟動IPv6。在中國，移動、聯(lián)通和電信大范圍開展現(xiàn)網(wǎng)IPv6試點。在中國下一代互聯(lián)網(wǎng)發(fā)展建設(shè)峰會上，與會專家明確了重視Android系統(tǒng)的IPv6二次開發(fā)，并主要采用雙棧技術(shù)（RFC4213）[1]的方針。

隨著IPv6研究工作和實際部署的不斷開展，網(wǎng)絡(luò)遲早會進入純IPv6（IPv6-only）的時代?，F(xiàn)在人們提出了很多IPv6的過渡計劃，大多都遵循RFC5211[2]中提出的3個漸進階段：準備階段、過渡階段、后過渡階段。

目前很多的資源還在IPv4環(huán)境中，因此IPv6和IPv4網(wǎng)絡(luò)之間的互通尤為重要。在IPv6-only環(huán)境下，現(xiàn)有的硬件設(shè)備和軟件可以應(yīng)用到什么程度，訪問網(wǎng)絡(luò)會出現(xiàn)什么問題，以及如何解決這些問題并沒有明確的官方資料。

在研究領(lǐng)域，愛立信的J.Arkko等于2010年開始構(gòu)建IPv6-only辦公環(huán)境，并于2012年4月確定RFC6586[3]。WIDE Project從2011年9月開始在WIDE Camp構(gòu)建IPv6-only實驗環(huán)境，并提出草案[4]。

2012年11月中國下一代互聯(lián)網(wǎng)示范工程（CNGI）專家委員會主辦的IPv6過渡技術(shù)國際測試大會，對業(yè)內(nèi)支持IPv6過渡技術(shù)的產(chǎn)品進行了摸底測試，推進了設(shè)備的產(chǎn)業(yè)化進程。

本文對IPv6-only的網(wǎng)絡(luò)互通技術(shù)從過渡技術(shù)、訪問場景、應(yīng)用需求3方面進行分析，對其中涉及的IPv6-only network訪問IPv4 Internet場景，采用NAT64/DNS64[5-7]翻譯技術(shù)進行系統(tǒng)構(gòu)建和應(yīng)用測試分析，并對實際IPv6-only環(huán)境部署遇到的問題和網(wǎng)絡(luò)設(shè)計進行討論。

2 IPv6-only網(wǎng)絡(luò)互通技術(shù)

分析

2.1 過渡技術(shù)分析

數(shù)據(jù)中心、網(wǎng)絡(luò)提供商的網(wǎng)絡(luò)環(huán)境以及網(wǎng)絡(luò)地址的漸進情況如圖1所示。在現(xiàn)網(wǎng)IPv4環(huán)境下，普遍采用網(wǎng)絡(luò)地址翻譯（NAT）技術(shù)解決地址缺乏問題。隨著IPv4地址分配完畢和IPv6的發(fā)展，過渡環(huán)境中普遍采用雙棧。新出廠的終端將支持IPv6，用戶可以在數(shù)據(jù)中心、網(wǎng)絡(luò)提供商提供的IPv6-only網(wǎng)絡(luò)環(huán)境下工作。

IPv4到IPv6的過渡技術(shù)[8]分為雙棧、隧道和翻譯3種。3種過渡技術(shù)各有其優(yōu)缺點，應(yīng)針對不同場景配置不同的過渡技術(shù)。

從IPv4到IPv6的過渡形態(tài)來看，對于IPv6-only環(huán)境的新用戶，資源訪問應(yīng)包括4個類型：本地IPv6訪問、一次翻譯、雙重翻譯、隧道封裝。

當用戶訪問服務(wù)器時，首先采用本地模式，即IPv6 to IPv6。若主機和服務(wù)器在不同環(huán)境下，主機嘗試一次翻譯，即IPv6 to IPv4。若一次翻譯訪問失?。☉?yīng)用層網(wǎng)關(guān)（ALG）發(fā)生問題等原因），主機嘗試雙重翻譯，即IPv6 to IPv4 to IPv6。若一些應(yīng)用（如IPSec）在雙重翻譯模式下無法工作，則采用隧道封裝進行訪問，即IPv4 over IPv6。

2.2 訪問場景分析

本文涉及的IPv6-only環(huán)境的新用戶，應(yīng)用程序可能是IPv4或IPv6的，在邊緣網(wǎng)絡(luò)訪問IPv4 Internet或IPv6 Internet。

對于IPv4 Internet的訪問可分為[9]3種場景：

（1）使用IPv4訪問IPv4 Internet。

（2）使用IPv6訪問IPv4 Internet。

（3）使用IPv6訪問IPv6 Internet。

場景（1）對應(yīng)于現(xiàn)在的過渡階段，大量資源都在IPv4 Internet上，很多應(yīng)用還只支持IPv4?？刹捎肐Pv4 over IPv6隧道技術(shù)，如Public 4over6、Lightweight 4over6、DS-Lite技術(shù)等。用戶設(shè)備作為隧道發(fā)起點，網(wǎng)絡(luò)出口的路由器設(shè)備作為隧道匯聚點。也可采用雙重翻譯技術(shù)，如MAP-T、464XLAT技術(shù)。

場景（2）對應(yīng)于的用戶設(shè)備支持IPv6單棧?？刹捎靡淮畏g技術(shù)，如有狀態(tài)的NAT64/DNS64、無狀態(tài)的IVI技術(shù)等。網(wǎng)絡(luò)邊緣路由器支持雙棧。

對于IPv6 Internet的訪問，場景（3）即全網(wǎng)已升級為IPv6?？刹捎肐Pv6單棧進行本地訪問。若有用戶設(shè)備的上層應(yīng)用仍使用IPv4，則需要進行用戶側(cè)的翻譯。

2.3 應(yīng)用需求分析

IPv6-only邊緣網(wǎng)絡(luò)中用戶的應(yīng)用需求可分為：

（1）IPv4環(huán)境下流行應(yīng)用。

（2）IPv4/IPv6可以互通解決的各種應(yīng)用。

（3）IPv6環(huán)境下的殺手級應(yīng)用。

應(yīng)用（1）包括目前流行的操作系統(tǒng)、網(wǎng)絡(luò)應(yīng)用、網(wǎng)絡(luò)安全等。其中網(wǎng)絡(luò)應(yīng)用包括客戶/服務(wù)器（C/S）架構(gòu)和對等（P2P）架構(gòu)的應(yīng)用。

應(yīng)用（2）指針對現(xiàn)有特定社會需求或科學研究而開展的需要IPv4/IPv6互通解決的應(yīng)用，如異構(gòu)或同構(gòu)網(wǎng)絡(luò)間大數(shù)據(jù)傳輸?shù)瓤蒲袘?yīng)用。

目前運營商的地址短缺問題也可采用大規(guī)模網(wǎng)絡(luò)地址翻譯（LSN）或者地址+端口（A+P）等方式解決，此類應(yīng)用也列于應(yīng)用（2）。

應(yīng)用（3）指通過IPv6能夠提供更好解決方案的應(yīng)用，如網(wǎng)絡(luò)安全等。

3 IPv6-only網(wǎng)絡(luò)構(gòu)建及

應(yīng)用測試

3.1 網(wǎng)絡(luò)構(gòu)建分析

IPv6-only網(wǎng)絡(luò)構(gòu)建可通過4個維度進行分析：

（1）應(yīng)用：可分為普通應(yīng)用程序和應(yīng)用層網(wǎng)關(guān)（如嵌入地址的網(wǎng)絡(luò)內(nèi)容）。

（2）訪問：可分為本地、一次翻譯、雙重翻譯、隧道封裝。

（3）狀態(tài)：分有狀態(tài)和無狀態(tài)。

（4）操作系統(tǒng)：可從IPv6地址角度和域名解析角度進行分析。RFC4291[10]和RFC5156[11]中列舉了各種用途的IPv6地址，如單播地址、鏈路本地地址、站點本地地址、6to4、Teredo等各種特殊的地址。

根據(jù)以上分析，我們選取IPv6-only邊緣網(wǎng)絡(luò)環(huán)境中，新用戶使用IPv6訪問IPv4 Internet這個典型場景進行第一步的網(wǎng)絡(luò)環(huán)境構(gòu)建和互通技術(shù)分析。

3.2 網(wǎng)絡(luò)構(gòu)建

我們于2012年5月初在中國科學院計算機網(wǎng)絡(luò)信息中心4號樓辦公區(qū)構(gòu)建IPv6-only實驗網(wǎng)絡(luò)，針對IPv6-only訪問IPv4 Internet場景，采用NAT64/DNS64技術(shù)。

系統(tǒng)構(gòu)建如圖2所示。網(wǎng)絡(luò)翻譯器下行連接網(wǎng)絡(luò)控制器、無線網(wǎng)絡(luò)接入點（AP），對用戶終端提供網(wǎng)絡(luò)連接；上行連接三層以太網(wǎng)交換機，接入中國科技網(wǎng)（CSTNET）。

本實驗環(huán)境采用A10 Networks的AX2600-GCF網(wǎng)關(guān)實現(xiàn)NAT64/DNS64；用戶終端關(guān)閉IPv4，只打開IPv6；采用無狀態(tài)地址分配[12]，NAT64轉(zhuǎn)換前綴為2001：cc0：2003：2：：/64；DNS64服務(wù)器地址為2001：cc0：2003：2：：243；網(wǎng)絡(luò)配置時間為2012年5—7月。10名研發(fā)人員使用PC機、手機、平板電腦等終端設(shè)備在此網(wǎng)絡(luò)環(huán)境下測試。

3.3 網(wǎng)絡(luò)應(yīng)用測試

網(wǎng)絡(luò)應(yīng)用測試主要測試IPv4環(huán)境中流行的應(yīng)用，包括操作系統(tǒng)和網(wǎng)絡(luò)應(yīng)用。網(wǎng)絡(luò)應(yīng)用包括客戶/服務(wù)器架構(gòu)和對等（P2P）架構(gòu)的應(yīng)用。

3.3.1 操作系統(tǒng)

測試了Windows7、WindowsXP、Ubuntu10.04、Fedora16、Android4.0、Mac10.6等操作系統(tǒng)。

Windows7、Ubuntu10.04、Mac10.6、Android4.0支持IPv6-only。其中，采用Android4.0的用戶終端需進入開發(fā)模式配置靜態(tài)IPv6域名服務(wù)器（DNS）。Mac10.6系統(tǒng)用于鄰居發(fā)現(xiàn)的地址（默認IPv6地址）和用于接送發(fā)送標識的地址需指定為同一地址。

WindowsXP不支持IPv6-only。其原因是WindowsXP沒有安裝IPv6的部分支持協(xié)議如DHCPv6等。

Fedora16無法支持IPv6-only。在實驗中配置了IPv4后可使用IPv6。Fedora的網(wǎng)絡(luò)管理器的IPv6基于IPv4連接。2012年5月更新的Fedora17可支持IPv6-only。

3.3.2 網(wǎng)絡(luò)應(yīng)用——網(wǎng)頁

在IPv6-only環(huán)境下，我們測試了IE9、Firefox、Chrome3款瀏覽器，均可訪問IPv4（只有A記錄）網(wǎng)站，其中Chrome須在配置頁面打開IPv6功能。

目前的網(wǎng)站分為僅有A記錄（指向IPv4地址的記錄）的網(wǎng)站（Yahoo中國、新浪等），以及同時具有AAAA記錄（指向IPv6地址的記錄）和A記錄的網(wǎng)站（Yahoo.com、Google.com等）。

訪問網(wǎng)站時，根據(jù)NAT64/DNS64工作機制，DNS64首先查詢AAAA記錄，當存在AAAA記錄時，客戶端直接通過路由器進行IPv6訪問；當AAAA記錄不存在時，查詢A記錄，DNS64將網(wǎng)站地址轉(zhuǎn)換為IPv6地址發(fā)送給客戶端，客戶端通過NAT64翻譯發(fā)給路由器后，訪問網(wǎng)站。

我們進行了將DNS64設(shè)置為僅查詢A記錄的實驗，順利訪問Yahoo中國、新浪等IPv4網(wǎng)站，驗證了NAT64/DNS64機制的有效性。

3.3.3 網(wǎng)絡(luò)應(yīng)用——視頻

我們訪問了新浪、搜狐、優(yōu)酷、土豆、酷六等網(wǎng)站的視頻，其中僅新浪的大部分視頻可順利訪問。經(jīng)抓包分析，新浪的大部分視頻采用按照域名對視頻文件進行查詢的方式，而其他網(wǎng)站視頻采用的是按照IPv4地址進行查詢。NAT64/DNS64無法解決IPv4地址嵌入的情況。

3.3.4 網(wǎng)絡(luò)應(yīng)用——客戶端應(yīng)用程序

我們測試了QQ、MSN、Renren、Skype等即時通信客戶端程序，均無法通信，即利用數(shù)據(jù)報協(xié)議（UDP）的客戶端通信基于IPv4，無法在IPv6-only環(huán)境下工作。

根據(jù)RFC6120[13]中對可擴展通信和表示協(xié)議（XMPP）的定義，服務(wù)器的標識等應(yīng)采用域名。因此相應(yīng)地，Web QQ、Web MSN、Web Renren、Web Weibo等基于XMPP協(xié)議或超文本傳輸協(xié)議（HTTP）的通信可以正常工作，除非嵌入IPv4地址。

3.4測試結(jié)論與討論

從測試結(jié)果來看，構(gòu)建IPv6-only網(wǎng)絡(luò)環(huán)境是可行的，滿足辦公的基本需求。目前很多硬件軟件都支持IPv6，但并不能完全支持IPv6-only，推薦采用最新的操作系統(tǒng)，如Window7、Mac10.6、Fedora17、Android4.0、Ubuntu10.04以上版本。

本次實驗采用網(wǎng)絡(luò)層的翻譯機制NAT64，對于嵌入IPv4地址的應(yīng)用程序，需要設(shè)置應(yīng)用層網(wǎng)關(guān)配合NAT64工作，或采用應(yīng)用層的翻譯機制。以文件傳輸協(xié)議（FTP）為例，工作方式分為主動模式和被動模式，有IPv4環(huán)境中的FTP協(xié)議[14]和IPv6環(huán)境中的FTP協(xié)議[15]。在本次實驗場景的翻譯過程中需要在應(yīng)用層對嵌入IP地址的FTP指令及相應(yīng)連接參數(shù)做逐條翻譯，如EPSV到PASV，EPRT到PORT等[16]。

IPv6-only的實際部署，如對于不能訪問的采用地址進行索引的視頻的處理、只支持IPv4的網(wǎng)絡(luò)程序等，需要網(wǎng)絡(luò)內(nèi)容服務(wù)商（ICP）的支持?，F(xiàn)階段仍推薦采用雙棧。

實驗采用手工配置DNS和無狀態(tài)自動分配地址，需進一步測試基于路由器公告（RA）的DNS自動發(fā)現(xiàn)和DHCPv6功能。

4 總結(jié)及未來研究計劃

本文對IPv6-only網(wǎng)絡(luò)互通技術(shù)從過渡技術(shù)、訪問場景、應(yīng)用需求3方面進行分析。對IPv6-only網(wǎng)絡(luò)中的用戶訪問IPv6 Internet的場景采用NAT64/DNS64進行系統(tǒng)構(gòu)建，在基本應(yīng)用測試的基礎(chǔ)上進行了分析。

近期討論的實驗包括IPv6-only環(huán)境中IPSec等安全性測試和FTP等需配置應(yīng)用層網(wǎng)關(guān)的應(yīng)用測試等。

未來我們將著重于IPv6-only環(huán)境下雙重翻譯和隧道技術(shù)的應(yīng)用及基于科學問題的網(wǎng)絡(luò)互通研究。

IPv6-only是IPv4/IPv6過渡的完成階段，面對目前因特網(wǎng)工程任務(wù)組（IETF）中提出的面對各種場景的過渡技術(shù)，IPv6-only如何在應(yīng)用、訪問、狀態(tài)、操作系統(tǒng)等4個維度上同現(xiàn)有網(wǎng)絡(luò)環(huán)境實現(xiàn)更好的互通是非常重要的研究領(lǐng)域，將促進IPv6的進一步發(fā)展和推廣。

參考文獻

[1] NORDMARK E， GILLIGAN R. Basic transition mechanisms for IPv6 hosts and routers [S]. RFC4213. 2005.

[2] CURRAN J. An Internet transition plan [S]. RFC5211. 2008.

[3] ARKKO J， KERANEN A. Experiences from an IPv6-only network [S]. RFC6586. 2012.

[4] HAZEYAMA H， HIROMI R， ISHIHARA T， et al. Experiences from IPv6-only networks with transition technologies in the WIDE camp autumn 2012 [R]. draft-hazeyama-widecamp-ipv6-only-experience-02. 2012.

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

[6] BAGNULO M， SULLIVAN A， MATTHEWS P， et al. DNS64： DNS extensions for network address translation [S]. RFC6147. 2011.

[7] IPv4 Exhaustion and IPv6 transition [J]. Nikkei Network， 2011， 10（7）：30-35.

[8] AMOSS J J， MINOLI D. Handbook of IPv4 to IPv6 transition： Methodologies for institutional and corporate networks [M]. New York， NY，USA： Auerbach Publications， 2007.

[9] 崔勇. IPv6過渡場景分析 [R]. 北京： 中國通信標準化協(xié)會， 2012.

[10] HINDEN R S， DEERING S. IP version 6 addressing architecture [S]. RFC4291. 2006.

[11] BLANCHET M. Special-use IPv6 addresses [S]. RFC5156. 2008.

[12] THOMSON S， NARTEN T， JINMEI T. IPv6 stateless address autoconfiguration [R]. RFC4862. 2007.

[13] SAINT-ANDRE P. Extensible messaging and presence protocol （XMPP）： Core [S]. RFC6120. 2011.

[14] POSTEL J， REYNOLDS J. File Transfer Protocol [S]. RFC0959. 1985.

[15] ALLMAN M， OSTERMANN S， METS C. FTP Extensions for IPv6 and NATs [S]. RFC2428. 1998.

[16] BEIJNUM VAN I. An FTP Application Layer Gateway （ALG） for IPv6-to-IPv4 Translation [S]. RFC6384. 2011.