IPv4發(fā)展到今天已存在著諸多缺陷，比如地址枯竭、安全和服務(wù)質(zhì)量難以保證、路由膨脹等，這些問題將極大制約云計(jì)算等相關(guān)IT行業(yè)的發(fā)展。IPv6以其更大的地址空間、更高的安全性等特點(diǎn)，能夠很好的解決IPv4這些缺陷。

UCloud于2018年上半年開始研發(fā)公網(wǎng)入口的IPv6轉(zhuǎn)換，依托NAT64技術(shù)和可編程P4交換機(jī)，現(xiàn)已成功推出了免費(fèi)的UCloud公網(wǎng)入口IPv6轉(zhuǎn)換服務(wù)。該產(chǎn)品功能簡(jiǎn)潔易用，申請(qǐng)EIP后一鍵開啟IPv6轉(zhuǎn)換，無需任何改造，即可對(duì)外提供IPv6的訪問。目前，UCloud IPv6轉(zhuǎn)換服務(wù)已成功用于云主機(jī)、EIP、負(fù)載均衡、容器集群、堡壘機(jī)等產(chǎn)品。地域內(nèi)單集群(16臺(tái)NAT64服務(wù)器，4臺(tái)P4交換機(jī))最高可實(shí)現(xiàn)3.2M CPS和1.6G的并發(fā)連接，且可在以后的演進(jìn)過程中平滑擴(kuò)容。

UCloud IPv6演進(jìn)戰(zhàn)略步驟對(duì)于IPv6技術(shù)的預(yù)研與探索，UCloud早在幾年之前就已經(jīng)開始了，內(nèi)部已有完整的IPv6預(yù)研方案。但我們?nèi)孕枰逦恼J(rèn)識(shí)到網(wǎng)絡(luò)基礎(chǔ)設(shè)施的改造不是一蹴而就的，這里面不僅涉及到技術(shù)難題的攻克，其本身還是個(gè)非常巨大的工程問題。

而且最重要的是在不影響用戶現(xiàn)有業(yè)務(wù)的同時(shí)，讓用戶的業(yè)務(wù)慢慢的遷移至IPv6。正是基于這種考慮，針對(duì)IPv4到IPv6的演進(jìn)，UCloud制定了以下戰(zhàn)略：

1. 2018年完成互聯(lián)網(wǎng)入口IPv6轉(zhuǎn)換服務(wù)，使UCloud超過百分之五十的產(chǎn)品能夠支持IPv6，客戶只需在EIP開啟IPv6轉(zhuǎn)換服務(wù)，無需更改任何業(yè)務(wù)即可使業(yè)務(wù)獲得對(duì)外提供IPv6訪問服務(wù)的能力，實(shí)現(xiàn)業(yè)務(wù)和IPv6網(wǎng)絡(luò)的平滑對(duì)接;

2. 2018年完成管理網(wǎng)IPv6改造，使得依托于管理網(wǎng)的云產(chǎn)品諸如主機(jī)入侵檢測(cè)，容器鏡像庫(kù)等產(chǎn)品支持IPv6;

3. 2019年完成UCloud主要產(chǎn)品支持IPv6，其中VPC、ULB(UCloud負(fù)載均衡)等重要產(chǎn)品將于2019 Q2之前支持IPv6，具備主動(dòng)訪問IPv6網(wǎng)絡(luò)能力;

4. 2019年完成IDC雙棧改造，使得數(shù)據(jù)中心內(nèi)部支持IPv6，提供完整的IPv6支持。

IPv6從技術(shù)到落地的過程中，UCloud做了很多工作，也遇到了比較多的挑戰(zhàn)。本文接下來將從技術(shù)的角度詳細(xì)介紹UCloud IPv6轉(zhuǎn)換服務(wù)的實(shí)現(xiàn)與優(yōu)化演進(jìn)。

UCloud IPv6轉(zhuǎn)換服務(wù)

◆ NAT64及其技術(shù)挑戰(zhàn)

在實(shí)現(xiàn)技術(shù)上，UCloud使用有狀態(tài)的NAT64技術(shù)來實(shí)現(xiàn)IPv6轉(zhuǎn)換服務(wù)，NAT64是一種通過網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)形式促成IPv6與IPv4主機(jī)間通信的IPv6轉(zhuǎn)換機(jī)制。NAT64網(wǎng)關(guān)需要至少一個(gè)IPv4地址和一個(gè)包含32位地址空間的IPv6網(wǎng)段來完成IPv4與IPv6協(xié)議間的翻譯。

NAT64將這個(gè)32bit的IPv4地址嵌入的IPv6目的地址轉(zhuǎn)換成目的IPv4地址，源IPv6地址轉(zhuǎn)換成一個(gè)特定的源IPv4地址。NAT64網(wǎng)關(guān)則創(chuàng)建IPv6與IPv4地址間的映射，這可以為手動(dòng)配置，也可以自動(dòng)確定。

如下圖所示，UCloud IPv6轉(zhuǎn)換功能基于NAT64實(shí)現(xiàn)，可為用戶現(xiàn)有IPv4的EIP生成一個(gè)IPv6地址，在用戶不修改現(xiàn)有IPv4網(wǎng)絡(luò)和相應(yīng)服務(wù)的情況下，相應(yīng)云資源和服務(wù)可以獲得被公網(wǎng)IPv6訪問的能力，并可使得用戶的云資源和服務(wù)被IPv4和IPv6同時(shí)訪問。

IPv6與IPv4之間的轉(zhuǎn)換是一種有狀態(tài)轉(zhuǎn)換，考慮整個(gè)系統(tǒng)層面的穩(wěn)定性與擴(kuò)展性需求，IPv6轉(zhuǎn)換服務(wù)的實(shí)現(xiàn)主要有兩大技術(shù)關(guān)鍵點(diǎn)：

• 高可用，由于IPv6轉(zhuǎn)換服務(wù)是有狀態(tài)服務(wù)，因此必須保證在集群內(nèi)節(jié)點(diǎn)發(fā)生變化時(shí)，不能影響已有連接(準(zhǔn)確的說影響不超過1/n，其中n標(biāo)識(shí)后端節(jié)點(diǎn)數(shù)目);
• 安全防護(hù)，由于IPv6轉(zhuǎn)換服務(wù)是有狀態(tài)服務(wù)，因此當(dāng)碰到惡意攻擊(比如DDoS)，很容易導(dǎo)致服務(wù)器被打掛進(jìn)而導(dǎo)致服務(wù)不可用，因此一定的DDoS防護(hù)能力對(duì)整個(gè)系統(tǒng)來說至關(guān)重要。

◆ 系統(tǒng)架構(gòu)

根據(jù)以上關(guān)鍵點(diǎn)，我們開始著手設(shè)計(jì)基于NAT64和P4交換機(jī)實(shí)現(xiàn)IPv6轉(zhuǎn)換功能的系統(tǒng)架構(gòu)，如下圖所示，其中NAT64 Access使用P4交換機(jī)實(shí)現(xiàn)，通過NAT64 Access的一致性Hash實(shí)現(xiàn)高可用。同時(shí)在NAT64 Access對(duì)CPS進(jìn)行限速，實(shí)現(xiàn)DDoS防護(hù)。

NAT64 Access與物理交換機(jī)1組成三層網(wǎng)絡(luò)，通過BGP向物理交換機(jī)1宣告一個(gè)/96的IPv6地址段，作為該地域的IPv6 prefix。POP1與POP2中Access向外宣告的地址段相同，實(shí)現(xiàn)負(fù)荷分擔(dān)和POP點(diǎn)級(jí)別的容災(zāi)。同理，POP點(diǎn)內(nèi)兩個(gè)Access之間也是負(fù)荷分擔(dān)和容災(zāi)。

Access與物理交換機(jī)2以及NAT64服務(wù)器組成二層網(wǎng)絡(luò)，NAT64服務(wù)器北向通過BGP向Access宣告VIP，Access即可獲得VIP對(duì)應(yīng)的下一跳信息(MAC地址)。當(dāng)收到Internet流入的入向IPv6報(bào)文時(shí)，將所述報(bào)文的MAC地址設(shè)定為某個(gè)NAT64服務(wù)器的MAC地址，即可實(shí)現(xiàn)將報(bào)文送達(dá)至特定的NAT64服務(wù)器。同時(shí)NAT64服務(wù)器南向需要向物理交換機(jī)4宣告一個(gè)源地址池，實(shí)現(xiàn)回程的可達(dá)性。

需要說明的是，在實(shí)際部署中，物理交換機(jī)2和1通常合一部署，形成NAT64 Access以旁掛的形式存在。下面以云主機(jī)為例，通過業(yè)務(wù)流程來簡(jiǎn)要說明整個(gè)系統(tǒng)的工作機(jī)制：

• 業(yè)務(wù)流程

由于每個(gè)NAT64服務(wù)器上會(huì)配置一個(gè)源地址池且互不重疊(其中IPv4_1是NAT64源地址池中的一個(gè)地址，IPv4_2對(duì)應(yīng)EIP)并且南向通告了該地址池，因此云主機(jī)的響應(yīng)報(bào)文(目的地址為源地址池中的地址，即IPv4_1)能夠通過路由到達(dá)相應(yīng)的NAT64服務(wù)器。

◆ 當(dāng)P4遇見NAT64

NAT64 Access支持高可用

通過上文的系統(tǒng)架構(gòu)，可以發(fā)現(xiàn)，通過物理交換機(jī)可以實(shí)現(xiàn)POP點(diǎn)級(jí)別的負(fù)荷分擔(dān)和容災(zāi)，但是實(shí)際上系統(tǒng)能夠?qū)崿F(xiàn)高可用的關(guān)鍵在于當(dāng)NAT64服務(wù)節(jié)點(diǎn)的狀態(tài)發(fā)生變化(比如擴(kuò)容或者某個(gè)節(jié)點(diǎn)down)時(shí)，系統(tǒng)需要保證已有連接不被破壞，這就要求NAT64 Access選擇后端節(jié)點(diǎn)時(shí)能夠支持一致性Hash，因此實(shí)質(zhì)上NAT64 Access的最重要屬性是一致性Hash網(wǎng)關(guān)。

在各大云計(jì)算廠商的實(shí)現(xiàn)中，一致性Hash網(wǎng)關(guān)的實(shí)現(xiàn)，DPDK是當(dāng)前主流的實(shí)現(xiàn)方案。但是DPDK也存在以下缺陷：

• 基于DPDK的應(yīng)用可以達(dá)到很高的包轉(zhuǎn)發(fā)速率，但這是通過多服務(wù)器、多核負(fù)載均衡實(shí)現(xiàn)的。且負(fù)載均衡算法通常是由硬件交換機(jī)或者網(wǎng)卡實(shí)現(xiàn)，并不能被軟件定義。如果網(wǎng)絡(luò)中出現(xiàn)單個(gè)大象流，無法被硬件交換機(jī)或者網(wǎng)卡的負(fù)載均衡算法很好的分發(fā)，就會(huì)造成單根網(wǎng)線或者單個(gè)CPU Core出現(xiàn)擁塞，對(duì)業(yè)務(wù)造成巨大影響。
• 隨著網(wǎng)絡(luò)帶寬從10G向25G、40G、50G、100G的演進(jìn)，DPDK需要更強(qiáng)力的CPU才能夠達(dá)到線速，而更強(qiáng)力的CPU通常價(jià)錢也很昂貴，不利成本。特別是單Core的主頻越高，價(jià)格越貴，且主頻增加之間和價(jià)格增加是非線性關(guān)系。

因此，我們最終決定采用P4可編程交換機(jī)(基于Barefoot Tofino芯片實(shí)現(xiàn))來實(shí)現(xiàn)NAT64 Access，實(shí)際上UCloud早在2017年就開始預(yù)研P4可編程交換機(jī)，并且目前已有基于P4可編程交換機(jī)的GW灰度上線。相比于DPDK網(wǎng)關(guān)，P4可編程交換機(jī)具有諸多優(yōu)勢(shì)：

1. 與DPDK相比，有更高的轉(zhuǎn)發(fā)性能(1.8T~6.4T);

2. 轉(zhuǎn)發(fā)性能穩(wěn)定，不受CPU Loading等影響;

3. 單線100G，可以避免單線擁塞;

4. P4語(yǔ)言開放性好，可編程能力強(qiáng);

5. 很好的生態(tài)圈，支持P4 Runtime。

Maglev Hash

Maglev算法的選擇及驗(yàn)證

在一致性Hash算法的選擇時(shí)，我們選擇了Google Maglev項(xiàng)目中使用的 Hash算法(下文簡(jiǎn)稱Maglev Hash)，該算法的核心優(yōu)勢(shì)在于當(dāng)后端服務(wù)節(jié)點(diǎn)發(fā)生變化時(shí)，具有極致的穩(wěn)定性。并且Lookup表的size保持不變，非常適合于P4交換機(jī)來承載Lookup表。(原始論文：Maglev: A Fast and Reliable Software Network Load Balancer)

根據(jù)該論文中對(duì)一致性Hash的介紹可以看出，Maglev Hash算法本質(zhì)上設(shè)計(jì)算法讓每個(gè)后端按照一定的規(guī)則去填滿數(shù)組Lookup表的Empty Entry，確保所構(gòu)造出來的Lookup表的元素中，所有后端服務(wù)器出現(xiàn)的次數(shù)盡可能相等(實(shí)質(zhì)上，根據(jù)算法出現(xiàn)次數(shù)最多的節(jié)點(diǎn)和最少的節(jié)點(diǎn)之間的差值最大為1)，因此可以達(dá)到極致的平均性能。

Maglev Hash算法所產(chǎn)生的Lookup表，雖然有著極致的平均性能，但是也有一個(gè)缺陷，那就是當(dāng)后端服務(wù)節(jié)點(diǎn)發(fā)生變化時(shí)，會(huì)有部分連接中斷的情況(理想的一致性Hash算法中斷連接的比例為1/N，Maglev Hash可能存在略微超過1/N)。

在Maglev項(xiàng)目中，通過Connection Track表來彌補(bǔ)這一缺陷，然而Connection Track將帶來一系列缺點(diǎn)，使得NAT64 Access有狀態(tài)，易于收到攻擊。從論文中可以看出，當(dāng)Lookup表的size大于后端節(jié)點(diǎn)的100倍時(shí)，連接中斷的情況低于2%。但是2%還是一個(gè)相對(duì)比較高的比例，本著嚴(yán)謹(jǐn)?shù)膽B(tài)度，我們?cè)跀U(kuò)容和縮容(縮容也對(duì)應(yīng)某臺(tái)NAT64服務(wù)器Down機(jī))場(chǎng)景下又針對(duì)Lookup表size與后端節(jié)點(diǎn)的比例進(jìn)行了一系列測(cè)試與驗(yàn)證。

上圖分別對(duì)應(yīng)于后端節(jié)點(diǎn)增加和減少的情況，通過上述測(cè)試可以發(fā)現(xiàn)，當(dāng)Lookup表的size較小時(shí)，該算法的穩(wěn)定性略差，以上述測(cè)試為例，當(dāng)Lookup表的size為1024時(shí)，在擴(kuò)容和縮容場(chǎng)景，會(huì)有將近百分之二的連接會(huì)受到影響(具體表現(xiàn)為entry改變)，這點(diǎn)與論文Maglev論文中的結(jié)論基本一致。

但是隨著Lookup表的size增大，對(duì)已有連接的影響越來越小，最終逼近與1/n。具體到上述兩圖，當(dāng)Lookup表的大小超過后端服務(wù)節(jié)點(diǎn)的2000倍時(shí)，連接中斷的比例低于0.01%，但是由于沒有connection track，整個(gè)NAT64 Access是無狀態(tài)的，這就大大提升了NAT64 Access的穩(wěn)定性，并且極大的減小了實(shí)現(xiàn)復(fù)雜度。

NAT64 Access的工作原理

NAT64 Access上承載著一張Lookup表，格式如下：

需要說明的是，此處的Lookup表實(shí)際上是由Maglev中數(shù)張Lookup表構(gòu)成的，通過vip加以區(qū)分。

具體工作機(jī)制如下：

不同的NAT64集群通過BGP向NAT64 Access宣告不同的VIP， NAT64 Manager通過GRPC獲取NAT64 Access的路由表信息和鄰居表信息，獲取各個(gè)VIP以及對(duì)應(yīng)的下一跳MAC地址信息。然后遍歷所有VIP，根據(jù)每個(gè)VIP的下一跳信息調(diào)用Maglev Hash Engine生成相應(yīng)的每個(gè)集群的entry list(具體值為各個(gè)NAT64的MAC地址)。所有的entry list以及VIP構(gòu)成上述Lookup表。

當(dāng)數(shù)據(jù)面收到報(bào)文時(shí)，將根據(jù)EIP查詢到VIP(通過另外的表以及控制面相應(yīng)邏輯實(shí)現(xiàn)，在此不再展開)，然后根據(jù)數(shù)據(jù)包的源IP、目的IP、源端口、目的端口、調(diào)用P4語(yǔ)言的Hash函數(shù)通過計(jì)算得到entry index，最后根據(jù)VIP和entry index匹配Lookup表，設(shè)置目的MAC，至此就完成了后端服務(wù)節(jié)點(diǎn)的選擇。

NAT64 Manager將持續(xù)監(jiān)控NAT64 Access的路由表以及鄰居表，一旦某個(gè)VIP的下一跳發(fā)生了改變(比如擴(kuò)容場(chǎng)景或者某個(gè)NAT64 Down)，將重新調(diào)用Maglev Hash Engine重新生成該VIP對(duì)應(yīng)的Lookup表中對(duì)應(yīng)的那部分entry，并通過GRPC修改相應(yīng)的entry，實(shí)現(xiàn)節(jié)點(diǎn)變化時(shí)的快速響應(yīng)。

NAT64 Access DDoS安全防護(hù)

由于IPv6轉(zhuǎn)換服務(wù)本身是有狀態(tài)的，也就意味著有可能受到DDoS的攻擊，因此我們?cè)贜AT64 Access上對(duì)每個(gè)EIP針對(duì)TCP SYN報(bào)文進(jìn)行入向和出向PPS限速。因?yàn)閁Cloud在公網(wǎng)接入有著強(qiáng)大的安全保護(hù)和DDoS檢測(cè)、清洗等，因此NAT64 Access上所執(zhí)行的SYN報(bào)文的限速僅僅是作為一個(gè)補(bǔ)充和二次防護(hù)。但是其優(yōu)點(diǎn)在于無需檢測(cè)分析而直接進(jìn)行限速，這可以使得在極端攻擊場(chǎng)景下縮短N(yùn)AT64服務(wù)的不可用時(shí)間(安全中心完整的DDoS防護(hù)通常都存在檢測(cè)和分析等步驟，存在一定程度的滯后性)。

目前單個(gè)EIP的SYN報(bào)文的速率限制在50000，超過50000時(shí)會(huì)進(jìn)行丟包。該參數(shù)是可調(diào)的，如果用戶業(yè)務(wù)層面有超大CPS的需求，UCloud相關(guān)的技術(shù)支持人員也可以協(xié)助進(jìn)行調(diào)整。

P4表配置優(yōu)化

Tofino芯片包含4條pipeline，每個(gè)pipeline包含12個(gè)stage，目前主流的場(chǎng)景還是所有pipeline使用相同的表配置，即使用同一份P4代碼。但是一旦兩個(gè)表之間相互依賴，就沒辦法放入同一個(gè)stage，這是底層芯片的執(zhí)行邏輯決定的。

考慮業(yè)務(wù)邏輯的復(fù)雜性，數(shù)據(jù)面通常需要定義很多的表才可以完成整個(gè)業(yè)務(wù)邏輯，且這些表之間彼此依賴性很高。因此在實(shí)際編碼過程中出現(xiàn)了stage用光，但是每個(gè)stage資源利用率很低，具體到我們的項(xiàng)目，資源利用率低就會(huì)導(dǎo)致一臺(tái)NAT64 Access能夠支持的EIP數(shù)量有限。這種問題通常有以下三種解決方案：

• 優(yōu)化表配置，或者修改一定的業(yè)務(wù)邏輯，減少表之間的相互依賴，這樣能夠大大提高stage資源的利用率;
• 由于ingress和egress雖然共享stage，但是ingress和egress的表之間從硬件層面沒有任何依賴關(guān)系。因此將業(yè)務(wù)邏輯拆分，一部分放于ingress，另一部分放于egress。這種方案比較簡(jiǎn)單易行，且通常收效明顯;
• Pipeline串行，拆分業(yè)務(wù)邏輯，每個(gè)pipeline放置一部分業(yè)務(wù)邏輯，不同pipeline之間通過自定義metadata傳遞信息。這種方案也是一種行之有效的方案，且能夠提升Tofino整體的表項(xiàng)空間，可以預(yù)見未來可能會(huì)有很多這樣的應(yīng)用。

在NAT64項(xiàng)目中，我們采用了1和2結(jié)合的方案，經(jīng)過優(yōu)化后，資源利用率達(dá)到百分之七十左右(沒有優(yōu)化之前只達(dá)到百分之三十左右)。下圖是我們優(yōu)化后Tofino芯片的資源利用圖和Table占用圖。

系統(tǒng)性能測(cè)試

系統(tǒng)構(gòu)建完成后，我們針對(duì)單臺(tái)NAT64(NAT64服務(wù)器配置為CPU：32核;內(nèi)存：64GB;網(wǎng)卡： X710 10Gb * 2)服務(wù)器進(jìn)行了完整的性能測(cè)試，client是IPv6，server端是IPv4 雙向udp數(shù)據(jù)流，一應(yīng)一答。client發(fā)送請(qǐng)求到server，server端應(yīng)答回到client。其中最為關(guān)鍵的CPS和并發(fā)連接數(shù)指標(biāo)測(cè)試結(jié)果如下：

• CPS測(cè)試結(jié)果：

• 并發(fā)連接數(shù)測(cè)試結(jié)果：

我們初始單set上線了16臺(tái)NAT64服務(wù)器，因此單地域最高可實(shí)現(xiàn)3.2M CPS和1.6G的并發(fā)連接。此外，整個(gè)系統(tǒng)支持平滑的無縫擴(kuò)容，支持任意添加NAT64 Access和NAT64服務(wù)器。

當(dāng)前，UCloud IPv6轉(zhuǎn)換服務(wù)處于免費(fèi)公測(cè)階段，歡迎使用。