將IPv6照進現實，我們需要做些什么？
隨著中共中央辦公廳、國務院辦公廳印發了《推進互聯網協議第六版(IPv6)規模部署行動計劃》后，整個 IPv6 產業鏈開始活躍起來。雖然目前我們距離世界上每一粒沙子都有一個地址的夢想還有點遠，但加速推進的大趨勢應該是不爭的事實。但是我們在仰望星空的同時還需要腳踏實地，那么 IPv6 的現實是怎樣的呢，我們還需要準備什么呢，這就是這篇文章想要表達的。
IPv6這個曾經以解決地址短缺問題而出現的技術存在了很久，但因為種種原因沒在世界范圍內普及，尤其是沒在中國普及。今天的文章不是 IPv6 科普文章，也沒有過多的涉及到網絡如何改造，業務如何適配，更多的是從用的角度來看現狀。另外從我個人角度，移動網 IPv6 化會走在固網 IPv6 的前面，移動網應該是雙棧的策略，所以文章的分析都是以移動網為前提，固網暫不涉及。
手機支持雙棧嗎?
IPv6 在相當長一段時間內沒能夠在公眾網中普及，很重要的一個原因就是各方的動力不足，雖然一直在宣傳 IPv4 地址不夠用了，但縫縫補補還是讓互聯網走了這么多年。如果拋開動力不足來看，IPv6 的普及其實是一個系統工程，需要的是端、管、云，三方的協同支持，那么我們先看下端，也就是手機的支持情況。
首先是蘋果 iPhone，對于 v6 蘋果早在幾年前就強推 APP 對于 IPv6 only 的支持，如果不通過這個功能審核是不能上架 App Store 的。但當時對于 APP 開發者來說最為郁悶的是在國內很難找到一個商用的 IPv6 Only 環境進行測試，更多是 Mac 熱點或者 WiFi APP 來模擬進行網絡庫的邏輯測試，在移動網下是沒有辦法做測試的。而這樣的問題在目前 IPv6 改造期間一樣面臨，即在國內蘋果 iPhone 在移動網下只能獲得 v4 地址，沒有 v6 地址。為什么呢，因為 iPhone 里面的 APN 設置是不能修改的，而內置 APN 中對于地址請求所攜帶的字段僅僅是 IPv4 類型，這樣即使網絡支持雙棧，iPhone 還是只能獲得v4地址，下圖就是一個蘋果手機在移動網內的信令請求：
?? 
上面標黃的地方顯示 PDN type 為 IPv4。如果雙棧的話，這里的 type 類型是IPv4IPv6。在國家機構，運營商的聯合推動下，蘋果手機從 iOS12.1 開始已經開啟了默認雙棧的支持。
下面該談到 Android 了，安卓相對來說開放一些的，大多數的手機都可以支持 APN協議編輯，并且部分手機已經缺省設置變成了 IPv4IPv6 雙棧協議支持，如下截圖：
?? 
但在這里還有幾個坑需要告知：
- 不是所有的安卓手機都可以編輯 APN 協議類型。
- 即使可以編輯 APN 協議類型，也不是所有的手機都會把 IPv4/IPv6 作為缺省協議。
- 有些手機盡管是支持雙棧的，但從系統 API 里面是看不到所獲得的 IPv6 地址，但如果你同時開了 WiFi，奇跡出現了，v6 地址又出來了。
碎片化的安卓帶來了碎片化的雙棧支持，這對客戶端進行當前網絡環境判斷帶來了很大挑戰。
移動運營商現在支持雙棧嗎，手機得到的地址有什么玄機?
說完了端，下一步就需要看看管，即運營商到底對于 v6支持的現狀如何，策略如何?如開篇所說拋開固網不談，在移動網的場景下，三大運營商都已經開通了IPv4IPv6 的雙棧支持。不過需要說明的是，這里的雙棧支持管道特指下圖中從空口到移動核心網這里，至于骨干網和阿里網絡的雙棧支持要根據各個運營商的互聯情況來看。
?? 
下面看下在某運營商網絡下終端拿到的地址信息：
?? 
一般用戶回拿到 IPv4v6 雙棧地址，v6地址的 DNS 不是必須的有些省份可能沒有，但在雙棧情況下只要 DNS 能支持 AAAA 記錄的解析查詢即可。
下面就是要進入重要的 IPv6 地址獲得環節了，即以上的2409開頭的 v6地址客戶端是怎么獲得到呢，這個地址有什么玄機嗎?移動網內手機和網絡通訊有兩個面，一個是控制面也就是俗稱的信令面，這個層面 APP 是感知不到的，另一個是用戶面，即APP 正常的業務數據流都走在這里。在 IPv4 only 的場景下，手機地址的獲得單純通過控制面的信令交互即可，但在 IPv4 IPv6 雙棧場景下，流程就發生了一些變化。先來看信令面：
?? 
Create Session Request 是手機發給核心網的，里面攜帶了幾個重要的信息：
?? 
PDN Type 字段需要是 IPv4/IPv6， PDN Address and Prefix(IPv6) 是全零。
Create Session Response 是核心網對手機的響應。
?? 
里面包含了類似 PDN AddressPrefix 和 DNS Server 的信息，但你可能會很奇怪發現這個 Prefix 不是一個真正的 Prefix，也和手機獲得到的地址格式有很多差異。
這時候就需要再看一下用戶面的消息：
?? 
根據 IPv6 地址分配規則，FE80開頭的是鏈路單播地址，FF02::1是所有開啟了 IPv6組播的主機，再來看下 Router Advertisement 消息：
?? 
這個消息就包含了重要的 Prefix 字段，這是基于 IPv6 stateless Autonomous Address-Configuration(SLACC) 的實現，從后續的數據流可以看到，手機收到了這個64位的前綴后補充了后面的64位組合成完整的128位IPv6地址作為源地址進行正常的業務訪問。不過稍微有一點疑問的是這后面的64位地址是怎么生成的，從多次測試來看每次后64位都是變化的，由于在手機上構造包需要 root，所以后續條件具備情況下會進行通過構造不同后64位的數據報文來進行測試，看看網絡是不是僅靠前64位來識別用戶的。
接著就面臨到了最后一個問題，即這個地址有玄機嗎?128位的地址一方面讓人很難記，另一方面也給地址掃描造成了巨大的難度，如果這些地址都是完全隨機的，那么對于那些依賴地址信息的后端業務來說將是巨大的災難。不過運營商幫我們在一定程度上解決了這個問題，但他們的出發點是為了更好的監管，也就是在文章片頭的那句世界上的每一粒沙子都有一個地址后面要加上世界上每一粒沙子都是可被追蹤的。
根據工信部2014年發布的《YD/T 2682-2014 IPv6接入地址編址編碼技術要求》，其中對用戶設備接入地址結構的指導性意見為：
?? 
其中：
- PB 為 IPv6 接入地址塊前綴，長度為 n 的比特串。
- AI 是編址標識符，長度為 s+t 的比特串，包括長度為 s 的省份標識符和長度為 t 的接入類型表示符兩部分。其中接入類型包括固網動態接入、固網靜態接入、移動蜂窩接入。
- CC 是區/縣編碼，長度為 8 位。在工信部的文件附錄，明確了全國各區縣的具體8位編碼。
- SSI 是子網標識符，長度為56-n-s-t。
- IID 是接口標識符，長度64位。
國內三大運營商都基于此技術要求做了進一步的細化，這里不再描述細節，但從地址大段上來看中國移動使用的2409:8000::/20IPv6地址，中國聯通使用的2408:8000::/20 IPv6地址，中國電信則有240E::/24、240E::/20、2001:0C68 ::/32、2001:07FA:0010::/48、2402:8800::/32 五塊地址。
不過這里需要說明的是目前雙棧僅在 4G 下開啟，也就是說回到 2G 會變成 IPv4 only，這又該客戶端對于當前網絡環境判斷增加了變數;還有就是由于目前地址具有了一定的位置屬性，那么跨區縣移動場景下的地址分配怎么處理還暫不明確。
Happy EyeBall 問題
在手機，網絡和服務端全鏈路支持雙棧的場景下，手機首先要面對的就是一個選擇問題，即一個域名會解析出來 A 和 AAAA 記錄，簡化來說就是兩個地址，同時返回兩個地址，怎么選擇?一個快，一個慢怎么選擇?一個出問題怎么選擇?地址選擇好了才能有后續的建連，才會有業務發生，所以這個選擇策略很重要。如果從體驗角度出發，誰快連誰這是最簡單的邏輯，但在當前 v4 網絡好于 v6 的大環境下這樣的邏輯只會讓 v6 的普及變得更為艱難，因此針對這個問題，IET F先起了一個名字叫 Happy Eyeball，接著發布了兩份 RFC 來描述推薦的處理邏輯，最新的是 RFC8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency，有興趣的可以去閱讀下，這里只摘抄出最重要的一段：
The algorithm proceeds as follows: if a positive AAAA response (a responsewith at least one valid AAAA record) is received first, the first IPv6connection attempt is immediately started. If a positive A response is receivedfirst due to reordering, the client SHOULD wait a short time for the AAAAresponse to ensure that preference is given to IPv6 (it is common for the AAAAresponse to follow the A response by a few milliseconds). This delay will bereferred to as the "Resolution Delay". The recommended value for theResolution Delay is 50 milliseconds. If a positive AAAA response is receivedwithin the Resolution Delay period, the client immediately starts the IPv6connection attempt.
簡單來說就是 RFC 建議優選 IPv6，且給 AAAA 記錄的返回留50毫秒的容忍期。
由于系統的限制，這樣選擇邏輯的落地是客戶端網絡庫無關的，基于網絡材料來看目前各系統的具體實現：
蘋果 iOS：在 v4 和 v6 雙協議棧的情況下，從 ios9 開始蘋果會發出 A 和 AAAA 記錄的 DNS 請求，如果首先收到了 DNS 的 AAAA 記錄返回，那么蘋果會馬上發出v6 的 syn，如果首先收到了 A 記錄的返回，會有一個 25ms 的定時器，如果超時了就會發送 v4 syn，如果在這個定時器內收到 AAAA 就會發送 v6 的 syn。這個機制和 Happy Eyeball 基本一致，只是等待時長不同，蘋果會不會修改到 RFC 建議值未知。
Android：優選 v6，但等待時長未知。
這樣的機制從理論上就會出現由于這個等待時長造成業務體驗的下降。
還有 NAT 嗎，會有 PAT 嗎，還有防火墻嗎?
在移動網只有 IPv4 的場景下，手機用戶訪問服務端的整個鏈路中必不可少的一個中間設備就是運營商的防火墻，一方面為了應對 v4 地址稀缺的問題，設備會做公私網的地址翻譯，為了更進一步的復用地址，還會做端口翻譯，另一方面為了安全性考慮，設備會做一些類似 ACL 的安全策略，通常只會允許出方向的訪問，同時為了降低對于設備的負荷，還會做一些超時的設置，斷開那些空閑較長的連接。而這樣的限制對于服務端某些過度依賴地址的應用，對于端口轉換不友好的應用，對于需要長期保活的應用都會產生一定的影響，那么在 IPv4v6 雙棧的場景下如何呢，我做了如下的測試：在一臺有公網 IPv6 地址的服務器上簡單用 python 寫了一個開啟80端口的服務端：
Server start at:2400:3200:1000:xx:::80
wait for connection...
在手機上執行busybox telnet 2400:3200:1000:xx:: 80 命令
這是服務端打出的日志
Connected by('2409:8928:84e:995:xxxx:xxxx:xxxx:xxxx', 34102, 0, 0)
其中 Connected by ('2409:8928:84e:995:xxxx:xxxx:xxxx:xxxx 為服務端看到的手機地址，34102為對應的端口號，那么這個地址和端口號是不是手機自身的呢，去手機上看一下：
odin:/ $ busyboxnetstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.84.66.147:43623 111.13.134.131:443 CLOSE_WAIT
tcp 0 0 10.84.66.147:46051 140.205.34.21:443 ESTABLISHED
tcp 0 0 ::ffff:10.84.66.147:49856 ::ffff:112.13.64.13:5333 ESTABLISHED
tcp 0 0 ::ffff:10.84.66.147:37201 ::ffff:39.106.239.196:443 ESTABLISHED
tcp 0 0 ::ffff:10.84.66.147:55440 ::ffff:118.194.55.183:5223 ESTABLISHED
tcp 0 0 2409:8928:84e:995:3b4a:38ce:8ead:1972:34102 2400:3200:1000:xxxx:::80ESTABLISHED
從上面輸出來看，運營商的中間設備沒有做 NAT，也沒有做 PAT，服務端看到了手機發出的原始的源地址和源端口，當然防火墻還是有的，主動從服務端還是不能訪問手機。
MTU問題
從協議頭來看 v4 和 v6 有一個比較重要的差異就是 Don’t Fragment bit 這個位一直開的，也就是由于一直是開的所以在 IPv6 的頭里面就沒有明示這個字段，如果有fragment 就會增加一個 Fragemention Header。由于網絡中間支持 v6 的路由器不會對對 IPv6 包進行分片，所以如果一個包過大那么路由器會產生 ICMP6 Type2 數據包，內含 Packet Too Big (PTB) 和 MTU 信息返回給發送方，這樣機制看上去比較好，但是由于中間設備可能會過濾掉 PTB 數據包造成這樣的通知發送方收不到影響正常傳輸，因此發送方最好在開始的時候就不要發送過大的數據包，目前一個建議參考值 MTU 是1280字節。
?? 
未結束的結束語
IPv6 的序幕剛剛拉開，這篇文章也僅是粗淺的初步分析，拋磚引玉。隨著時間的推移，文中的一些舉例也可能隨著網絡演進或者策略更改而變化，所以若有不對的地方還請見諒，希望在后面的過程中能夠積累沉淀出更多的實踐和思考，提升 IPv6 下的業務體驗。
【本文為51CTO專欄作者“阿里巴巴官方技術”原創稿件，轉載請聯系原作者】
