幹壞事是進步最大的原動力
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
Amazon Route 53 也宣佈支援 IPv6 了：「Amazon Route 53 Now Supports DNS Queries over IPv6 Networks」。
依照說明應該是無痛切換過去：
The change is seamless and requires no action from you; your end users and clients can begin making DNS queries over IPv6 immediately.
不過測了 heroku.com 的 NS RR (拿 ns-405.awsdns-50.com 測試)，還是只有 A record 啊？另外測了其他幾個也是 (反而沒找到已經切過去的？)，不知道是不是分批切換...
Amazon CloudFront 宣佈支援 IPv6 了：「IPv6 Support Update – CloudFront, WAF, and S3 Transfer Acceleration」。
不只是 Amazon CloudFront 支援了 IPv6，還包括了使用 CloudFront 而建出的 AWS WAF 與 Amazon S3 Transfer Acceleration。
所以對外的部份都有 IPv6 了 (包括了 ELB)，現在不支援的應該是內部機器與 Elastic IP address？
開放 IPv6 存取 Amazon S3 了：「Now Available – IPv6 Support for Amazon S3」。
對應的 Endpoint 是 http://BUCKET.s3.dualstack.REGION.amazonaws.com 與 http://s3.dualstack.REGION.amazonaws.com/BUCKET。
值得注意的是所有功能都開放 IPv6 了，包括 BitTorrent (還記得嗎 XDDD 如果忘記的，可以參考「Using BitTorrent with Amazon S3 這篇的說明」)：
S3 Feature Support – IPv6 support is available for all S3 features with the exception of Website Hosting, S3 Transfer Acceleration, and access via BitTorrent.
Update：寫太快發現早上匆匆忙忙出門寫錯了，是「不支援」，感謝 Twitter 上被提醒了：
@gslin “with the exception of” 應該是說 S3 不支援在BitTorrent 上使用 IPv6。
— cheungpat (@cheungpat) August 12, 2016
接下來是等 Amazon EC2 與 Amazon CloudFront 的支援...
Let's Encrypt 的公告出來了：「Full Support for IPv6」。
之前在看 http-01 challenge 時都是走 IPv4 認證，現在宣佈可以走 IPv6 了：
Let’s Encrypt is happy to announce full support for IPv6.
Apple 對 iOS 程式的新政策：「Supporting IPv6-only Networks」。
也就是說，在 ISP 提供 NAT64 的環境下 client 想要連 210.61.183.31 時會連 IPv6 的位置 ::d23d:b71f，ISP 會幫忙 NAT 出去。而client 端的應用程式要能夠在這樣的網路環境下正常運作。
這測試環境沒建過，不知道會遇到什麼問題... @_@
IPv6 address 表示法的確有不少問題，說「包袱」是因為應該是很難改了。
在「The IPv6 Numeric IP Format is a Serious Usability Problem」這篇文章裡作者討論 IPv6 address 表示法的問題，像是因為用 colon 切割造會跟 url 裡的 port 混淆，於是引入了 bracket 的 workaround：
An IPv4 URL of the form http://127.0.0.1:1234/ indicates that HTTP should be used to access a service at 127.0.0.1 port 1234. But what does http://dead:beef::1:1234/ mean? To fix the ambiguity, brackets were introduced. Now you have to type http://[dead:beef::1]:1234/.
Address Shortening Obfuscation 這邊講的就有點過火了，不過的確是不好讀，一眼看過去不是很容易切開一個 colon 與兩個 colon 的部份。
作者有提出一些建議方法，不過看起來只是 murmuring... XD
想說應該會有 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 好像還有得調，尤其是亞洲地區...