馬晨昊/MA Chenhao，解沖鋒/XIE Chongfeng，鄭偉/ZHENG Wei，李聰/LI Cong

（1.中國電信股份有限公司研究院，北京 102209；2.中國電信股份有限公司江蘇分公司，江蘇 南京，210037）

(1.China Telecom Research Institute, Beijing 102209, China;2.China Telecom Jiangsu Branch, Nanjing 210037, China)

作為新一版互聯(lián)網(wǎng)網(wǎng)絡(luò)層協(xié)議，IPv6在全球受到越來越多的重視。根據(jù)谷歌最新統(tǒng)計(jì)，現(xiàn)在全球約有30%的用戶開始使用IPv6，其中以歐美發(fā)達(dá)國家的IPv6發(fā)展最為領(lǐng)先。在2016年，IETF就發(fā)表聲明，要求新的協(xié)議制定或協(xié)議擴(kuò)展不要兼容IPv4，而要基于IPv6。在中國，自從2017年底中共中央辦公廳和國務(wù)院辦公廳發(fā)布IPv6行動計(jì)劃發(fā)布以來，在運(yùn)營商和OTT（指互聯(lián)網(wǎng)公司越過運(yùn)營商）等產(chǎn)業(yè)各界的協(xié)作下，中國IPv6發(fā)展迅速，分配了IPv6地址的用戶數(shù)、IPv6活躍用戶數(shù)和流量增長迅速。與此同時(shí)，作為新一代移動通信技術(shù)，5G也處于商用化部署的關(guān)鍵期。選擇合適的網(wǎng)絡(luò)協(xié)議和最佳功能配置是發(fā)展5G的關(guān)鍵。5G和IPv6是構(gòu)建中國新一代信息基礎(chǔ)設(shè)施的兩項(xiàng)重要技術(shù)支柱，它們在新時(shí)期的相遇和融合，是信息技術(shù)發(fā)展的必然。幸運(yùn)的是，在3GPP標(biāo)準(zhǔn)設(shè)計(jì)和設(shè)備實(shí)現(xiàn)上，5G已能良好地支持IPv6協(xié)議；但是5G網(wǎng)絡(luò)引入IPv6協(xié)議的技術(shù)路線，在3GPP的相關(guān)標(biāo)準(zhǔn)中并沒有詳細(xì)和明確的說明。例如，如何發(fā)揮IPv6的技術(shù)優(yōu)勢來提升網(wǎng)絡(luò)的綜合能力？如何處理IPv6和IPv4的關(guān)系？等。5G網(wǎng)絡(luò)引入IPv6涉及端、管、云等多個(gè)環(huán)節(jié)，如果處理不好，會對未來5G網(wǎng)絡(luò)甚至互聯(lián)網(wǎng)的發(fā)展產(chǎn)生不利影響。在5G SA部署過程中，是延續(xù)傳統(tǒng)繼續(xù)部署雙棧，還是破舊立新，直接采用IPv6單棧？針對以上問題，本文中，我們在分析5G網(wǎng)絡(luò)引入IPv6面臨的挑戰(zhàn)的基礎(chǔ)上，重點(diǎn)介紹和分析了不同的IPv6過渡方案，特別論述了5G SA網(wǎng)絡(luò)用戶面引入IPv6單棧的新型技術(shù)方案，并對其組網(wǎng)架構(gòu)、冗余備份、端口映射和溯源方案做了詳細(xì)介紹。在以上論述的基礎(chǔ)上，提出了運(yùn)營商選擇IPv6演進(jìn)路線的策略建議。

1 5G引入IPv6的主要問題及可選技術(shù)方案

5G引入IPv6主要涉及3個(gè)層面：用戶面、控制面和承載面。用戶面是與用戶數(shù)據(jù)傳輸相關(guān)的層面，它直接面向用戶終端并直接為用戶提供接入服務(wù)，是IP地址消耗最大的層面；控制面是指核心網(wǎng)設(shè)備之間的互連并且進(jìn)行核心網(wǎng)協(xié)議交互的層面；承載面是指城域網(wǎng)、骨干網(wǎng)等用于承載控制面和用戶面的網(wǎng)絡(luò)。每個(gè)層面都涉及到IPv6引入，策略上也會有所不同?？紤]到篇幅因素，我們主要討論用戶面的IPv6引入問題。5G引入IPv6時(shí)，所使用的技術(shù)方案原則上不影響5G原有功能和性能，并且盡可能發(fā)揮IPv6的技術(shù)優(yōu)勢來創(chuàng)建能力更高、成本更低的網(wǎng)絡(luò)。當(dāng)前5G引入IPv6的需要考慮如下幾個(gè)因素：

1）海量多業(yè)務(wù)承載。5G需要承載的業(yè)務(wù)更加多樣，不僅支持傳統(tǒng)的寬帶上網(wǎng)業(yè)務(wù)，還要支持物聯(lián)網(wǎng)（IoT）、移動邊緣計(jì)算（MEC）、車用無線通用技術(shù)（V2X）等新興業(yè)務(wù)，這主要對IP網(wǎng)絡(luò)層提出IP地址數(shù)足夠多、連接足夠多、業(yè)務(wù)保持高穩(wěn)定互通的要求。

2）高性能保障。5G網(wǎng)絡(luò)性要求更為苛刻，同時(shí)4K/8K高清視頻、遠(yuǎn)程醫(yī)療、云游戲、遠(yuǎn)程駕駛、工業(yè)控制等增強(qiáng)移動寬帶（eMBB）/超可靠低時(shí)延通信（URLLC）應(yīng)用需求也日趨緊迫，它們對網(wǎng)絡(luò)提出了超低時(shí)延、超大帶寬的要求。而這些性能需求與網(wǎng)絡(luò)用戶面緊密相關(guān)，需要用戶面提供高效的數(shù)據(jù)處理和轉(zhuǎn)發(fā)。

3）安全可溯源。由于面向的場景更加多樣，5G的連接數(shù)將會達(dá)到一個(gè)較高的數(shù)量級，所傳遞的內(nèi)容也將更為復(fù)雜。出于安全考慮，用戶面須提供完善的尋址方案和溯源方案，以確保用戶和終端的訪問行為可追溯。

目前中國的IPv6部署主要采用雙棧方式。網(wǎng)絡(luò)給用戶終端分配和維護(hù)IPv4地址和IPv6地址[1]，支持IPv6業(yè)務(wù)和IPv4業(yè)務(wù)的訪問，兩種協(xié)議邏輯上獨(dú)立。由于當(dāng)前IPv4地址極其稀缺，因此移動網(wǎng)絡(luò)通常給用戶分配私有IPv4地址，并在網(wǎng)絡(luò)中部署支持網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）的設(shè)備進(jìn)行公私有地址的轉(zhuǎn)換。隨著時(shí)間的推移，雙棧技術(shù)方案也日益暴露其缺點(diǎn)，例如：雙棧并沒有解決地址不足問題，有些場景下用戶的私有地址也發(fā)生沖突；此外，雙協(xié)議棧的維護(hù)成本高等。

IPv6單棧方案是以IPv6為基礎(chǔ)協(xié)議建立的終端編址和業(yè)務(wù)承載體系。該方案構(gòu)建在翻譯技術(shù)的基礎(chǔ)上，在終端只有IPv6地址的情況下，支持對IPv6和IPv4業(yè)務(wù)的訪問。該方案的核心是NAT64/DNS64（DNS指域名系統(tǒng)）技術(shù)。NAT64[2]是一種有狀態(tài)的網(wǎng)絡(luò)地址與協(xié)議轉(zhuǎn)換技術(shù)，用于IPv6客戶端和IPv4業(yè)務(wù)端傳輸控制協(xié)議（TCP）、用戶數(shù)據(jù)報(bào)協(xié)議（UDP）、Inernet控制報(bào)文協(xié)議（ICMP）下的 IPv6與IPv4網(wǎng)絡(luò)地址和協(xié)議轉(zhuǎn)換，實(shí)現(xiàn)只擁有IPv6地址的終端發(fā)起連接訪問IPv4側(cè)網(wǎng)絡(luò)資源。

在IPv6單棧網(wǎng)絡(luò)中，終端從網(wǎng)絡(luò)側(cè)只獲得IPv6地址，終端上存在支持IPv6的應(yīng)用客戶端，也存在只支持IPv4的應(yīng)用客戶端。如圖1所示，當(dāng)終端發(fā)起連接訪問普通IPv6網(wǎng)站或其他服務(wù)器時(shí)，流量將會匹配IPv6默認(rèn)路由并直接轉(zhuǎn)發(fā)至IPv6路由器處理，正常訪問IPv6網(wǎng)絡(luò)中的資源。

當(dāng)客戶端去訪問只支持IPv4協(xié)議棧的網(wǎng)站或服務(wù)器時(shí)，其目的IPv4地址需要由DNS64[3]服務(wù)器添加IPv6前綴Pref64來合成IPv6地址。其過程為：終端向支持DNS64的DNS遞歸服務(wù)器發(fā)出AAAA類解析請求時(shí)，如果權(quán)威服務(wù)器返回的記錄為RCODE=3（名字錯(cuò)誤，表示請求中的域不存在），說明該域名對應(yīng)的服務(wù)器為IPv4單棧服務(wù)器。此時(shí)DNS64繼續(xù)查詢，發(fā)出A類請求查詢，并獲得A類查詢結(jié)果。DNS64支持將DNS查詢信息中的 A記錄（IPv4地址）合成到 AAAA記錄（IPv6地址）中，即為IPv4 應(yīng)用服務(wù)器的IPv4地址通過添加IPv6前綴Pref64映射成了IPv6地址，并將生成的AAAA類結(jié)果返回給客戶端。

在有些情況下，IPv4網(wǎng)絡(luò)側(cè)的IPv4地址沒有經(jīng)過DNS64的處理直接到達(dá)IPv6單棧客戶端里。此時(shí)，支持RFC7050協(xié)議[4]的DNS64服務(wù)器會把前綴Pref64下發(fā)至終端，終端可使用本地合成前綴的方式將目的IPv4地址合并成IPv6地址。

在獲得AAAA類的解析結(jié)果后的該流量將被路由轉(zhuǎn)發(fā)至NAT64路由器上，IPv6與IPv4地址和協(xié)議在NAT64上進(jìn)行合成轉(zhuǎn)換，從而實(shí)現(xiàn)訪問IPv4網(wǎng)絡(luò)中的資源。需要補(bǔ)充說明的是，NAT64設(shè)備中將IPv4地址合成IPv6地址采用的前綴Pref64與DNS64中采用的合成前綴Pref64是一致的。

2 5G SA引入IPv6單棧的技術(shù)方案

2.1 5G組網(wǎng)方案

結(jié)合3GPP的5G標(biāo)準(zhǔn)[5]和IPv6單棧的思路，我們建議的組網(wǎng)方案如圖2所示。在IPv6單棧接入的環(huán)境下，終端只被分配了IPv6地址。為了支持IPv6單棧終端訪問支持IPv4協(xié)議的網(wǎng)站或者應(yīng)用，在5G的用戶面功能（UPF）位置部署支持NAT64設(shè)備，并在部署的DNS服務(wù)器上升級支持DNS64和RFC7050協(xié)議，通過IPv4和IPv6翻譯實(shí)現(xiàn)對于IPv4網(wǎng)站或者應(yīng)用的訪問。對于NAT64和DNS64的部署方式，NAT64的部署可采取分布式、集中式或混合式。我們建議運(yùn)營商根據(jù)實(shí)際需求選擇具體部署方式。

在實(shí)際的部署中NAT64存在兩種形態(tài)：插卡式NAT64設(shè)備和具備NAT64功能的專用設(shè)備。它們的部署方案也因此略有不同，具體介紹如下：

1）插卡式NAT64設(shè)備。插卡式NAT64方案如圖3所示，NAT64板卡插于用戶邊緣路由器（CE）路由器上。正常狀態(tài)下，板卡之間負(fù)載分擔(dān)，若一塊板卡發(fā)生故障，正常板卡承擔(dān)全部業(yè)務(wù)。設(shè)備的冗余建議采用熱備的方式備份，并且配置一致，同步NAT64會話信息，主備切換后用戶無感知。在尋址和路由方面，我們建議不同的CE配置不同的IPv4地址池，配置相同的IPv6合成前綴Pref64。在IPv6側(cè)發(fā)布相同的IPv6合成前綴Pref64，在IPv4側(cè)由于IPv4地址池不同，因此發(fā)布不同的IPv4路由。

2）具備NAT64功能的專用設(shè)備。專用設(shè)備方案如圖4所示，建議將設(shè)備側(cè)掛于CE上路由器，設(shè)備之間通過接口互聯(lián)。設(shè)備的冗余采用“1+1”的方式，正常狀態(tài)下兩臺設(shè)備之間負(fù)載分擔(dān)，若一臺故障，另一臺設(shè)備提供冗余。兩臺設(shè)備間通過熱備方式備份，并且同步NAT64會話信息，主備切換后用戶無感知。在尋址和路由方面和上述方案一樣，主備設(shè)備配置不同的IPv4地址池和相同的IPv6合成前綴Pref64，相互備份的兩臺NAT64設(shè)備在IPv6側(cè)發(fā)布相同的IPv6合成前綴Pref64，在IPv4側(cè)發(fā)布不同的路由。

NAT64功能除了用上述的專用硬件方式實(shí)現(xiàn)外，也可以采用虛擬化技術(shù)來實(shí)現(xiàn)。虛擬化NAT64的組網(wǎng)方案和物理設(shè)備的功能相同，和其他設(shè)備的互連接口也相同；不同之處僅在于NAT64功能在虛擬機(jī)上實(shí)現(xiàn)，考慮到篇幅，在此不做詳述。

2.2 端口映射方案

圖2 5G 獨(dú)立組網(wǎng)網(wǎng)絡(luò)架構(gòu)圖

圖3 插卡式NAT64/運(yùn)營商級NAT（CGN）方案

圖4 專用的NAT64設(shè)備方案

由于IPv4資源稀少，因此在NAT64中用戶的IPv6地址和IPv4地址并不是一一對應(yīng)的。通常情況下，多個(gè)用戶共享復(fù)用單個(gè)IPv4地址，此時(shí)需要進(jìn)行地址變換和端口層面的映射，并動態(tài)建立映射會話。基于端口級建立映射會話，在溯源系統(tǒng)中需要存儲大量的用戶連接信息表。這會對NAT64設(shè)備、溯源系統(tǒng)以及設(shè)備間的交互接口都帶來很大的壓力。

為了減小溯源日志的數(shù)據(jù)量，我們建議使用用戶動態(tài)分配“IPv4地址+端口段”（簡稱“IPv4端口段”）的方式，即采用用戶IPv6地址和IPv4端口段進(jìn)行動態(tài)映射的方式，將映射從端口級提到端口段級。具體方式列舉如下。

1）當(dāng)IPv6終端發(fā)起訪問IPv4應(yīng)用的請求時(shí)（數(shù)據(jù)上行）：

（1）對于目的IPv6地址，在NAT64中做IPv6和IPv4協(xié)議和地址轉(zhuǎn)換，此過程為無狀態(tài)；

（2）對于IPv6終端的源地址，在收到用戶終端發(fā)出的首個(gè)數(shù)據(jù)包時(shí)，NAT64為源IPv6地址從資源池中動態(tài)選取一個(gè)可用的IPv4端口段，將源IPv6地址變換為該IPv4端口段所在的IPv4地址，并將該IPv6數(shù)據(jù)包及后續(xù)使用該IPv6地址的數(shù)據(jù)包的源端口變換為該IPv4端口區(qū)間內(nèi)的端口，利用該端口段在NAT64中建立和維護(hù)TCP和UDP的會話映射，在使用完畢后釋放該IPv4端口段。

2）當(dāng)數(shù)據(jù)流返回時(shí)（數(shù)據(jù)下行）：

（1）對于目的IPv4地址，根據(jù)NAT64設(shè)備中的映射會話將目的地址從IPv4轉(zhuǎn)換成IPv6地址，同時(shí)進(jìn)行端口和協(xié)議的轉(zhuǎn)換；

（2） 對 于 源IPv4地 址，在NAT64中添加NAT64的映射前綴Pref64，做IPv4到IPv6地址和協(xié)議的轉(zhuǎn)換。

此外，為了支持從IPv4訪問IPv6的需求，我們建議NAT64需要同時(shí)支持通過手工配置靜態(tài)映射關(guān)系，實(shí)現(xiàn)IPv4網(wǎng)絡(luò)主動發(fā)起連接訪問IPv6網(wǎng)絡(luò)。

2.3 漫游考慮

IPv6單棧對5G網(wǎng)絡(luò)漫游的影響可以從兩個(gè)場景來分析：運(yùn)營商內(nèi)的省間漫游和出國漫游。對于第一種場景，運(yùn)營商在各省的網(wǎng)絡(luò)均具為IPv6單棧配置，因此漫游用戶在不改動終端配置的情況下可以使用IPv6單棧省份的環(huán)境，此時(shí)對于本地路由、回歸屬路由都沒有特別要求；對于第二種情況，如果被訪地的運(yùn)營商網(wǎng)絡(luò)不是IPv6單棧，此時(shí)終端可自動開啟雙棧模式，這樣可以使用非IPv6單棧的網(wǎng)絡(luò)環(huán)境訪問互聯(lián)網(wǎng)。

2.4 溯源方案

在5G IPv6單棧環(huán)境中，由于NAT64目前采用的是有狀態(tài)轉(zhuǎn)換方式，在設(shè)備的運(yùn)行過程中，NAT64設(shè)備需要實(shí)時(shí)保持IPv6地址和端口與IPv4地址和端口段間的映射關(guān)系。為了支持訪問溯源，我們建議將NAT64中映射表同步至日志服務(wù)器。

溯源方案如圖5所示，在5G IPv6單棧網(wǎng)絡(luò)中建立地址轉(zhuǎn)換日志系統(tǒng)，其中包括SYSLOG日志服務(wù)器、數(shù)據(jù)采集設(shè)備、溯源查詢服務(wù)器。多個(gè)服務(wù)器協(xié)同實(shí)現(xiàn)整個(gè)用戶溯源的流程，數(shù)據(jù)采集設(shè)備采集用戶和訪問日志信息，NAT64設(shè)備上傳用戶地址轉(zhuǎn)換記錄，兩個(gè)信息相關(guān)聯(lián)形成可供溯源功能的日志。NAT64地址轉(zhuǎn)換日志系統(tǒng)根據(jù)需求對現(xiàn)有系統(tǒng)進(jìn)行相應(yīng)擴(kuò)展，完成用戶地址映射信息的SYSLOG方式采集。此外，地址轉(zhuǎn)換系統(tǒng)應(yīng)能夠滿足用戶級的地址映射信息采集的功能和性能要求。

溯源系統(tǒng)的查詢過程就是通過給定的公網(wǎng)地址+端口號、映射關(guān)系建立的時(shí)間戳等信息來查詢用戶的源IPv6地址。這個(gè)源IPv6地址在IPv6單棧網(wǎng)絡(luò)中是用戶終端的公網(wǎng)IPv6地址。

3 IPv6單棧的產(chǎn)業(yè)發(fā)展現(xiàn)狀

IPv6單棧是網(wǎng)絡(luò)發(fā)展的國際趨勢。微軟、谷歌、蘋果和思科等支持IPv6單棧的發(fā)展，特別是谷歌和蘋果等在其iOS和Android終端產(chǎn)品中很早就實(shí)現(xiàn)了IPv6單棧的支持，即在給終端分配IPv6單棧地址的情況下，也可完成原有雙棧的功能。在運(yùn)營商方面，T-mobile、Sprint、Reliance Jio、Orange、SK、Telstra和Rogers等在4G時(shí)期就已經(jīng)部署或者試驗(yàn)了IPv6單棧技術(shù)；但在中國，對于IPv6單棧技術(shù)的規(guī)模驗(yàn)證仍然缺乏，因此需要加強(qiáng)規(guī)模部署的研究和現(xiàn)網(wǎng)實(shí)驗(yàn)。

4 運(yùn)營商5G網(wǎng)絡(luò)引入IPv6的路線選擇

IPv6單棧方案也可以解決網(wǎng)絡(luò)中IP地址不足帶來的編址問題。在傳統(tǒng)網(wǎng)絡(luò)中，不僅公有IPv4地址被耗盡，而且私有IPv4地址也緊缺，甚至?xí)l(fā)生私有地址復(fù)用的現(xiàn)象。新興業(yè)務(wù)如IoT、V2X和MEC等，對于編址提出了更高的要求，需要采用IPv6來解決編址問題。從雙棧演進(jìn)為IPv6單棧方案，在運(yùn)維方面簡化了網(wǎng)絡(luò)管理，減少了訪問控制列表（ACL）、路由配置和管理工作量。在安全方面，單棧替代雙棧，減少協(xié)議暴露面，降低了安全風(fēng)險(xiǎn)。終端采用唯一的公有IPv6地址也增強(qiáng)了溯源能力。

在當(dāng)前激烈的市場競爭中，運(yùn)營商注重業(yè)務(wù)的互通性和用戶的體驗(yàn)。在設(shè)備能力具備及部署合理的前提下，IPv6單棧技術(shù)方案可滿足運(yùn)營商這方面的要求。我們建議運(yùn)營商根據(jù)自己的IPv4地址富余量、產(chǎn)業(yè)情況、政府政策及終端支持等因素綜合考慮來選擇路線。下面對IPv6單棧技術(shù)與IPv4/IPv6雙棧技術(shù)的分析對比，具體如表1所示。

5 結(jié)束語

圖5 日志溯源系統(tǒng)組成示意圖

表1 雙棧方案和IPv6單棧方案的對比

移動網(wǎng)絡(luò)只給終端分配IPv6地址。在單IPv6地址的情況下，移動終端不但能支持IPv6單棧業(yè)務(wù)，也能支持對IPv4/IPv6雙棧及IPv4單棧業(yè)務(wù)的訪問，使用戶體驗(yàn)不會因?yàn)闆]有IPv4地址而發(fā)生變化。需要說明的是，IPv6單棧技術(shù)本身不提倡廣泛使用NAT64，而是希望實(shí)現(xiàn)NAT64轉(zhuǎn)化的流量在總流量中的占比越來越少，而端到端的IPv6流量占比越來越大，因此使OTT的業(yè)務(wù)向IPv6進(jìn)一步遷移。本文中，我們對5G引入IPv6的思路進(jìn)行了探討，介紹了IPv6單棧下5G的基本技術(shù)、組網(wǎng)方案、映射和溯源方案，為5G運(yùn)營商的IP網(wǎng)絡(luò)演進(jìn)技術(shù)路線的選擇提供參考。5G IPv6單?；瘜⑹蔷W(wǎng)絡(luò)向IPv6演進(jìn)的重要一步，除了技術(shù)的因素外，OTT企業(yè)和運(yùn)營商各方的協(xié)同合作也是最終關(guān)鍵的關(guān)鍵。

致謝

本研究的實(shí)驗(yàn)工作得到了國家下一代互聯(lián)網(wǎng)工程中心李震博士的協(xié)助，在此謹(jǐn)致謝意！