5G SA網(wǎng)絡(luò)引入IPv6的思路探討

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

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

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

5G引入IPv6主要涉及3個(gè)層面：用戶(hù)面、控制面和承載面。用戶(hù)面是與用戶(hù)數(shù)據(jù)傳輸相關(guān)的層面，它直接面向用戶(hù)終端并直接為用戶(hù)提供接入服務(wù)，是IP地址消耗最大的層面；控制面是指核心網(wǎng)設(shè)備之間的互連并且進(jìn)行核心網(wǎng)協(xié)議交互的層面；承載面是指城域網(wǎng)、骨干網(wǎng)等用于承載控制面和用戶(hù)面的網(wǎng)絡(luò)。每個(gè)層面都涉及到IPv6引入，策略上也會(huì)有所不同?？紤]到篇幅因素，我們主要討論用戶(hù)面的IPv6引入問(wèn)題。5G引入IPv6時(shí)，所使用的技術(shù)方案原則上不影響5G原有功能和性能，并且盡可能發(fā)揮IPv6的技術(shù)優(yōu)勢(shì)來(lái)創(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）、移動(dòng)邊緣計(jì)算（MEC）、車(chē)用無(wú)線(xiàn)通用技術(shù)（V2X）等新興業(yè)務(wù)，這主要對(duì)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)移動(dòng)寬帶（eMBB）/超可靠低時(shí)延通信（URLLC）應(yīng)用需求也日趨緊迫，它們對(duì)網(wǎng)絡(luò)提出了超低時(shí)延、超大帶寬的要求。而這些性能需求與網(wǎng)絡(luò)用戶(hù)面緊密相關(guān)，需要用戶(hù)面提供高效的數(shù)據(jù)處理和轉(zhuǎn)發(fā)。

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

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

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

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

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

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

在獲得AAAA類(lèi)的解析結(jié)果后的該流量將被路由轉(zhuǎn)發(fā)至NAT64路由器上，IPv6與IPv4地址和協(xié)議在NAT64上進(jìn)行合成轉(zhuǎn)換，從而實(shí)現(xiàn)訪(fǎng)問(wèn)IPv4網(wǎng)絡(luò)中的資源。需要補(bǔ)充說(shuō)明的是，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單棧終端訪(fǎng)問(wèn)支持IPv4協(xié)議的網(wǎng)站或者應(yīng)用，在5G的用戶(hù)面功能（UPF）位置部署支持NAT64設(shè)備，并在部署的DNS服務(wù)器上升級(jí)支持DNS64和RFC7050協(xié)議，通過(guò)IPv4和IPv6翻譯實(shí)現(xiàn)對(duì)于IPv4網(wǎng)站或者應(yīng)用的訪(fǎng)問(wèn)。對(duì)于NAT64和DNS64的部署方式，NAT64的部署可采取分布式、集中式或混合式。我們建議運(yùn)營(yíng)商根據(jù)實(shí)際需求選擇具體部署方式。

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

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

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

NAT64功能除了用上述的專(zhuān)用硬件方式實(shí)現(xiàn)外，也可以采用虛擬化技術(shù)來(lái)實(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)營(yíng)商級(jí)NAT（CGN）方案

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

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

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

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

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

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

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

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

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

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

2.3 漫游考慮

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

2.4 溯源方案

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

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

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

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

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

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

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

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

5 結(jié)束語(yǔ)

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

表1 雙棧方案和IPv6單棧方案的對(duì)比

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

致謝

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