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