幹壞事是進步最大的原動力
Facebook 在「Legacy support on IPv6-only infra」這邊提到機房內主要的流量幾乎都是 IPv6 了：
Today, 99 percent of our internal traffic is IPv6 and half of our clusters are IPv6-only.
不過只有一半的機器是 IPv6-only，這個比例看起來還有不少服務在 dual-stack 轉移階段... 然後從外部只有 15% 的流量是 IPv6：
Globally, however, only 15 percent of people who use Facebook have IPv6 support.
所以從外部連進來的時候必須轉換成 IPv6 資訊：
這張圖也解釋了 shiv 的角色，在 traceroute 的時候會看到他...
AWS 總算是把 EC2 推上 IPv6 了：「New – IPv6 Support for EC2 Instances in Virtual Private Clouds」。
不過只有在 US East (Ohio) (us-east-2) 有，而且 m3.* 與 g2.* 目前都還不支援：
IPv6 support for EC2 is now available in the US East (Ohio) Region and you can start using it today at no extra charge. It works with all current-generation EC2 instance types with the exception of M3 and G2, and will be supported on upcoming instance types as well.
看得到吃不到 XDDD
Apple 對 iOS 程式的新政策：「Supporting IPv6-only Networks」。
也就是說，在 ISP 提供 NAT64 的環境下 client 想要連 210.61.183.31 時會連 IPv6 的位置 ::d23d:b71f，ISP 會幫忙 NAT 出去。而client 端的應用程式要能夠在這樣的網路環境下正常運作。
這測試環境沒建過，不知道會遇到什麼問題... @_@
想說應該會有 extension 可以看連線是 IPv4 或是 IPv6，找了一下果然有：「IPvFoo」。
右上角會出現目前連線的屬性。透過 Google Chrome 提供的 webRequest 取得資訊後更新上去的。
目前比較常見的站台應該是 Facebook (包括 Instagram)、Google 與 Yahoo，也剛剛好都是 HTTPS Policy 的先驅... 不過可以看出來不是所有的資源都走 IPv6，還是有不少走 IPv4 的 domain。
Twitter 的主網站沒有 IPv6，但幾個自己的子網域有？看起來還在逐步測試開通...
HiNet 的 IPv6 服務已經可以透過網路櫃台直接線上申請 (需要幾個工作天開通)，我用 Ubuntu 可以 PPPoE 取得...
看到「North America is out of IPv4 addresses—for really real this time」這邊提到了北美 IPv4 位置的問題，檢查了一下發現我的 blog 還沒上 IPv6，先把 /etc/network/interfaces 設好，再把 DNS 與 nginx 改了一下就 okay 了。
這是 Google 所觀察到的 IPv6 使用率，可以在「IPv6 – Google」這邊看到：
如果時間軸拉的小一點，可以看出來週末會高一點，周間會低一點 XD
美國的 IPv4 位置配完了：「US exhausts IPv4 addresses」，其他的地區也差不多了。
然後愈來愈多網站推 IPv6 了，尤其是 CloudFlare 以吃到飽為號召 (固定金額不限流量)，所以有很多服務都掛在上面。另外流量大的應該是 YouTube 吧。
不過 routing 好像還有得調，尤其是亞洲地區...
當 ARIN 只剩下最後一個 /8 的 IPv4 位置時，將會啟動第四階段的發放機制，而昨天進入這個機制了：「ARIN Enters Phase Four of the IPv4 Countdown Plan」。
出自「ARIN IPv4 Countdown Plan」這頁。
目前的進度是：
不過 IPv6 的進展還是苦哈哈啊...
英國的 ISP BT Retail 開始測試 CGNAT (Carrier-grade NAT) 了：「BT Begins Customer Tests of Carrier Grade NAT」。
空前但未必是絕後的大型 NAT 計畫，如果 CGNAT 可行，IPv6 會再往後延個好幾年吧...
Update：被 comment 提醒跑去測試，發現中華的 3G 早就是了：(CGNAT 會用 100.64.0.0/10，範圍到 100.127.255.255)
目前的電腦與網路已經有能力一次掃完整個 IPv4：「The result of pinging all the Internet IP addresses」。
用 ping 不一定準確，因為目前 Windows 作業系統預設會開啟防火牆，不會接受 ping。不過仍然是個有趣的方法 :p
首先是整個 IPv4 address space 只有 7% 的 IP address 會回應 ICMP ping：
另外有各 /8 的回應數量：
可以看到很多是空的... XD
在 Slashdot 上看到 PlusNet 決定測試用 CGNAT (Carrier-grade NAT) 解決 IPv4 不夠的問題：「UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6」。
用超大型 NAT 並不是特別的新聞 (某些 mobile network 上就是這樣做)，但 ISP 如果用在一般網路上則很有可能會跟客戶的 NAT device (可能是公司，也可能是家庭) 發生 Private Network 相同而導致問題。
2012 年 4 月的 RFC 6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) 將 100.64.0.0/10 (Shared Address Space) 這個網段保留，拿來給營運 CGNAT 的 ISP 使用：
NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED NetHandle: NET-100-64-0-0-1 Parent: NET-100-0-0-0-0 NetType: IANA Special Use
在 RFC 裡規定 100.64.0.0/10 只能拿來內部使用不得交換；如果要交換必須要有能力將不同介面的 100.64.0.0/10 當作不同網段 NAT (也就是 CGNAT 會做的事情)：
In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.
另外文件裡還定義了使用 100.64.0.0/10 時對 DNS 的過濾。
如果 CGNAT 上不能打洞，那麼很多應用就很苦了 (得靠 UDP hole punching 打洞，這還得在沒有 randomized NAT port 的情況下才打的通)，不過非 P2P 的應用應該不會有問題...
會不會做一做之後就維持這個方式？IPv6 遙遙無期... XD