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轉換服務處于免費公測階段，歡迎使用。