IPv4發展到今天已存在著諸多缺陷，比如地址枯竭、安全和服務質量難以保證、路由膨脹等，這些問題將極大制約雲端計算等相關IT行業的發展。IPv6以其更大的地址空間、更高的安全性等特點，能夠很好的解決IPv4這些缺陷。

UCloud於2018年上半年開始研發公網入口的IPv6轉換，依託NAT64技術和可程式設計P4交換機，現已成功推出了免費的UCloud公網入口IPv6轉換服務。該產品功能簡潔易用，申請EIP後一鍵開啟IPv6轉換，無需任何改造，即可對外提供IPv6的訪問。目前，UCloud IPv6轉換服務已成功用於雲主機、EIP、負載均衡、容器叢集、堡壘機等產品。地域內單叢集（16臺NAT64伺服器，4臺P4交換機）最高可實現3.2M CPS和1.6G的併發連線，且可在以後的演進過程中平滑擴容。

UCloud IPv6演進戰略步驟

對於IPv6技術的預研與探索，UCloud早在幾年之前就已經開始了，內部已有完整的IPv6預研方案。但我們仍需要清晰的認識到網路基礎設施的改造不是一蹴而就的，這裡面不僅涉及到技術難題的攻克，其本身還是個非常巨大的工程問題。

而且最重要的是在不影響使用者現有業務的同時，讓使用者的業務慢慢的遷移至IPv6。正是基於這種考慮，針對IPv4到IPv6的演進，UCloud制定了以下戰略：

1.2018年完成網際網路入口IPv6轉換服務，使UCloud超過百分之五十的產品能夠支援IPv6，客戶只需在EIP開啟IPv6轉換服務，無需更改任何業務即可使業務獲得對外提供IPv6訪問服務的能力，實現業務和IPv6網路的平滑對接；

2.2018年完成管理網IPv6改造，使得依託於管理網的雲產品諸如主機***檢測，容器映象庫等產品支援IPv6；

3.2019年完成UCloud主要產品支援IPv6，其中VPC、ULB（UCloud負載均衡）等重要產品將於2019 Q2之前支援IPv6，具備主動訪問IPv6網路能力；

4.2019年完成IDC雙棧改造，使得資料中心內部支援IPv6，提供完整的IPv6支援。

IPv6從技術到落地的過程中，UCloud做了很多工作，也遇到了比較多的挑戰。本文接下來將從技術的角度詳細介紹UCloud IPv6轉換服務的實現與優化演進。

UCloud IPv6轉換服務

◆ NAT64及其技術挑戰

在實現技術上，UCloud使用有狀態的NAT64技術來實現IPv6轉換服務，NAT64是一種通過網路地址轉換（NAT）形式促成IPv6與IPv4主機間通訊的IPv6轉換機制。NAT64閘道器需要至少一個IPv4地址和一個包含32位地址空間的IPv6網段來完成IPv4與IPv6協議間的翻譯。

NAT64將這個32bit的IPv4地址嵌入的IPv6目的地址轉換成目的IPv4地址，源IPv6地址轉換成一個特定的源IPv4地址。NAT64閘道器則建立IPv6與IPv4地址間的對映，這可以為手動配置，也可以自動確定。

如下圖所示，UCloud IPv6轉換功能基於NAT64實現，可為使用者現有IPv4的EIP生成一個IPv6地址，在使用者不修改現有IPv4網路和相應服務的情況下，相應雲資源和服務可以獲得被公網IPv6訪問的能力，並可使得使用者的雲資源和服務被IPv4和IPv6同時訪問。

IPv6與IPv4之間的轉換是一種有狀態轉換，考慮整個系統層面的穩定性與擴充套件性需求，IPv6轉換服務的實現主要有兩大技術關鍵點：

高可用，由於IPv6轉換服務是有狀態服務，因此必須保證在叢集內節點發生變化時，不能影響已有連線（準確的說影響不超過1/n，其中n標識後端節點數目）；

安全防護，由於IPv6轉換服務是有狀態服務，因此當碰到惡意***（比如DDoS），很容易導致伺服器被打掛進而導致服務不可用，因此一定的DDoS防護能力對整個系統來說至關重要。

◆ 系統架構

根據以上關鍵點，我們開始著手設計基於NAT64和P4交換機實現IPv6轉換功能的系統架構，如下圖所示，其中NAT64 Access使用P4交換機實現，通過NAT64 Access的一致性Hash實現高可用。同時在NAT64 Access對CPS進行限速，實現DDoS防護。

NAT64 Access與物理交換機1組成三層網路，通過BGP向物理交換機1宣告一個/96的IPv6地址段，作為該地域的IPv6 prefix。POP1與POP2中Access向外宣告的地址段相同，實現負荷分擔和POP點級別的容災。同理，POP點內兩個Access之間也是負荷分擔和容災。

Access與物理交換機2以及NAT64伺服器組成二層網路，NAT64伺服器北向通過BGP向Access宣告VIP，Access即可獲得VIP對應的下一跳資訊（MAC地址）。當收到Internet流入的入向IPv6報文時，將所述報文的MAC地址設定為某個NAT64伺服器的MAC地址，即可實現將報文送達至特定的NAT64伺服器。同時NAT64伺服器南向需要向物理交換機4宣告一個源地址池，實現回程的可達性。

需要說明的是，在實際部署中，物理交換機2和1通常合一部署，形成NAT64 Access以旁掛的形式存在。下面以雲主機為例，通過業務流程來簡要說明整個系統的工作機制：

業務流程

由於每個NAT64伺服器上會配置一個源地址池且互不重疊（其中IPv4_1是NAT64源地址池中的一個地址，IPv4_2對應EIP）並且南向通告了該地址池，因此雲主機的響應報文（目的地址為源地址池中的地址，即IPv4_1）能夠通過路由到達相應的NAT64伺服器。

◆ 當P4遇見NAT64

NAT64 Access支援高可用

通過上文的系統架構，可以發現，通過物理交換機可以實現POP點級別的負荷分擔和容災，但是實際上系統能夠實現高可用的關鍵在於當NAT64服務節點的狀態發生變化（比如擴容或者某個節點down）時，系統需要保證已有連線不被破壞，這就要求NAT64 Access選擇後端節點時能夠支援一致性Hash，因此實質上NAT64 Access的最重要屬性是一致性Hash閘道器。

在各大雲端計算廠商的實現中，一致性Hash閘道器的實現，DPDK是當前主流的實現方案。但是DPDK也存在以下缺陷：

基於DPDK的應用可以達到很高的包轉發速率，但這是通過多伺服器、多核負載均衡實現的。且負載均衡演算法通常是由硬體交換機或者網絡卡實現，並不能被軟體定義。如果網路中出現單個大象流，無法被硬體交換機或者網絡卡的負載均衡演算法很好的分發，就會造成單根網線或者單個CPU Core出現擁塞，對業務造成巨大影響。
隨著網路頻寬從10G向25G、40G、50G、100G的演進，DPDK需要更強力的CPU才能夠達到線速，而更強力的CPU通常價錢也很昂貴，不利成本。特別是單Core的主頻越高，價格越貴，且主頻增加之間和價格增加是非線性關係。
因此，我們最終決定採用P4可程式設計交換機（基於Barefoot Tofino晶片實現）來實現NAT64 Access，實際上UCloud早在2017年就開始預研P4可程式設計交換機，並且目前已有基於P4可程式設計交換機的GW灰度上線。相比於DPDK閘道器，P4可程式設計交換機具有諸多優勢：

1.與DPDK相比，有更高的轉發效能（1.8T~6.4T）；

2.轉發效能穩定，不受CPU Loading等影響；

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

4.P4語言開放性好，可程式設計能力強；

5.很好的生態圈，支援P4 Runtime。

Maglev Hash

Maglev演算法的選擇及驗證

在一致性Hash演算法的選擇時，我們選擇了Google Maglev專案中使用的 Hash演算法（下文簡稱Maglev Hash），該演算法的核心優勢在於當後端服務節點發生變化時，具有極致的穩定性。並且Lookup表的size保持不變，非常適合於P4交換機來承載Lookup表。（原始論文：Maglev: A Fast and Reliable Software Network Load Balancer）

根據該論文中對一致性Hash的介紹可以看出，Maglev Hash演算法本質上設計演算法讓每個後端按照一定的規則去填滿陣列Lookup表的Empty Entry，確保所構造出來的Lookup表的元素中，所有後端伺服器出現的次數儘可能相等（實質上，根據演算法出現次數最多的節點和最少的節點之間的差值最大為1），因此可以達到極致的平均效能。

Maglev Hash演算法所產生的Lookup表，雖然有著極致的平均效能，但是也有一個缺陷，那就是當後端服務節點發生變化時，會有部分連線中斷的情況（理想的一致性Hash演算法中斷連線的比例為1/N，Maglev Hash可能存在略微超過1/N）。

在Maglev專案中，通過Connection Track表來彌補這一缺陷，然而Connection Track將帶來一系列缺點，使得NAT64 Access有狀態，易於收到***。從論文中可以看出，當Lookup表的size大於後端節點的100倍時，連線中斷的情況低於2%。但是2%還是一個相對比較高的比例，本著嚴謹的態度，我們在擴容和縮容（縮容也對應某臺NAT64伺服器Down機）場景下又針對Lookup表size與後端節點的比例進行了一系列測試與驗證。

上圖分別對應於後端節點增加和減少的情況，通過上述測試可以發現，當Lookup表的size較小時，該演算法的穩定性略差，以上述測試為例，當Lookup表的size為1024時，在擴容和縮容場景，會有將近百分之二的連線會受到影響（具體表現為entry改變），這點與論文Maglev論文中的結論基本一致。

但是隨著Lookup表的size增大，對已有連線的影響越來越小，最終逼近與1/n。具體到上述兩圖，當Lookup表的大小超過後端服務節點的2000倍時，連線中斷的比例低於0.01%，但是由於沒有connection track，整個NAT64 Access是無狀態的，這就大大提升了NAT64 Access的穩定性，並且極大的減小了實現複雜度。

NAT64 Access的工作原理

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

需要說明的是，此處的Lookup表實際上是由Maglev中數張Lookup表構成的，通過vip加以區分。

具體工作機制如下：

不同的NAT64叢集通過BGP向NAT64 Access宣告不同的VIP， NAT64 Manager通過GRPC獲取NAT64 Access的路由表資訊和鄰居表資訊，獲取各個VIP以及對應的下一跳MAC地址資訊。然後遍歷所有VIP，根據每個VIP的下一跳資訊呼叫Maglev Hash Engine生成相應的每個叢集的entry list（具體值為各個NAT64的MAC地址）。所有的entry list以及VIP構成上述Lookup表。

當資料面收到報文時，將根據EIP查詢到VIP（通過另外的表以及控制面相應邏輯實現，在此不再展開），然後根據資料包的源IP、目的IP、源埠、目的埠、呼叫P4語言的Hash函式通過計算得到entry index，最後根據VIP和entry index匹配Lookup表，設定目的MAC，至此就完成了後端服務節點的選擇。

NAT64 Manager將持續監控NAT64 Access的路由表以及鄰居表，一旦某個VIP的下一跳發生了改變（比如擴容場景或者某個NAT64 Down），將重新呼叫Maglev Hash Engine重新生成該VIP對應的Lookup表中對應的那部分entry，並通過GRPC修改相應的entry，實現節點變化時的快速響應。

NAT64 Access DDoS安全防護

由於IPv6轉換服務本身是有狀態的，也就意味著有可能受到DDoS的***，因此我們在NAT64 Access上對每個EIP針對TCP SYN報文進行入向和出向PPS限速。因為UCloud在公網接入有著強大的安全保護和DDoS檢測、清洗等，因此NAT64 Access上所執行的SYN報文的限速僅僅是作為一個補充和二次防護。但是其優點在於無需檢測分析而直接進行限速，這可以使得在極端***場景下縮短NAT64服務的不可用時間（安全中心完整的DDoS防護通常都存在檢測和分析等步驟，存在一定程度的滯後性）。

目前單個EIP的SYN報文的速率限制在50000，超過50000時會進行丟包。該引數是可調的，如果使用者業務層面有超大CPS的需求，UCloud相關的技術支援人員也可以協助進行調整。

P4表配置優化

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

考慮業務邏輯的複雜性，資料面通常需要定義很多的表才可以完成整個業務邏輯，且這些表之間彼此依賴性很高。因此在實際編碼過程中出現了stage用光，但是每個stage資源利用率很低，具體到我們的專案，資源利用率低就會導致一臺NAT64 Access能夠支援的EIP數量有限。這種問題通常有以下三種解決方案：

優化表配置，或者修改一定的業務邏輯，減少表之間的相互依賴，這樣能夠大大提高stage資源的利用率；
由於ingress和egress雖然共享stage，但是ingress和egress的表之間從硬體層面沒有任何依賴關係。因此將業務邏輯拆分，一部分放於ingress，另一部分放於egress。這種方案比較簡單易行，且通常收效明顯；
Pipeline序列，拆分業務邏輯，每個pipeline放置一部分業務邏輯，不同pipeline之間通過自定義metadata傳遞資訊。這種方案也是一種行之有效的方案，且能夠提升Tofino整體的表項空間，可以預見未來可能會有很多這樣的應用。
在NAT64專案中，我們採用了1和2結合的方案，經過優化後，資源利用率達到百分之七十左右（沒有優化之前只達到百分之三十左右）。下圖是我們優化後Tofino晶片的資源利用圖和Table佔用圖。

系統性能測試

系統構建完成後，我們針對單臺NAT64（NAT64伺服器配置為CPU：32核；記憶體：64GB；網絡卡： X710 10Gb * 2）伺服器進行了完整的效能測試，client是IPv6，server端是IPv4 雙向udp資料流，一應一答。client傳送請求到server，server端應答回到client。其中最為關鍵的CPS和併發連線數指標測試結果如下：

CPS測試結果：

併發連線數測試結果：

我們初始單set上線了16臺NAT64伺服器，因此單地域最高可實現3.2M CPS和1.6G的併發連線。此外，整個系統支援平滑的無縫擴容，支援任意新增NAT64 Access和NAT64伺服器。

當前，UCloud IPv6轉換服務處於免費公測階段，歡迎使用。