Facebook 機房內的 IPv6 架構

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 的時候會看到他...

VPC 環境下的 EC2 支援 IPv6

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

Route53 也支援 IPv6 了...

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 啊?另外測了其他幾個也是 (反而沒找到已經切過去的?),不知道是不是分批切換...

CloudFront 支援 IPv6

Amazon CloudFront 宣佈支援 IPv6 了:「IPv6 Support Update – CloudFront, WAF, and S3 Transfer Acceleration」。

不只是 Amazon CloudFront 支援了 IPv6,還包括了使用 CloudFront 而建出的 AWS WAFAmazon S3 Transfer Acceleration

所以對外的部份都有 IPv6 了 (包括了 ELB),現在不支援的應該是內部機器與 Elastic IP address

Amazon S3 開放 IPv6 存取

開放 IPv6 存取 Amazon S3 了:「Now Available – IPv6 Support for Amazon S3」。

對應的 Endpoint 是 http://BUCKET.s3.dualstack.REGION.amazonaws.comhttp://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 上被提醒了:

接下來是等 Amazon EC2Amazon CloudFront 的支援...

Apple 要求六月開始的 iOS 程式都必須能在 IPv6-only network 運作

Apple 對 iOS 程式的新政策:「Supporting IPv6-only Networks」。

也就是說,在 ISP 提供 NAT64 的環境下 client 想要連 210.61.183.31 時會連 IPv6 的位置 ::d23d:b71f,ISP 會幫忙 NAT 出去。而client 端的應用程式要能夠在這樣的網路環境下正常運作。

這測試環境沒建過,不知道會遇到什麼問題... @_@

IPv6 表示法的包袱

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

Google Chrome 上看連線是使用 IPv4 或是 IPv6

想說應該會有 extension 可以看連線是 IPv4 或是 IPv6,找了一下果然有:「IPvFoo」。

右上角會出現目前連線的屬性。透過 Google Chrome 提供的 webRequest 取得資訊後更新上去的。

目前比較常見的站台應該是 Facebook (包括 Instagram)、GoogleYahoo,也剛剛好都是 HTTPS Policy 的先驅... 不過可以看出來不是所有的資源都走 IPv6,還是有不少走 IPv4 的 domain。

Twitter 的主網站沒有 IPv6,但幾個自己的子網域有?看起來還在逐步測試開通...

HiNet 的 IPv6 服務已經可以透過網路櫃台直接線上申請 (需要幾個工作天開通),我用 Ubuntu 可以 PPPoE 取得...

把 blog.gslin.org 加上 IPv6 位置

看到「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