Debian/Ubuntu 上跑 6to4 的方法...

因為 HiNet 在自家放了 192.88.99.1 的 6to4 gateway,設起來玩看看?

網路上找了不少方法都不會動 (包括 Ubuntu 在官方 wiki「IPv6」上給的連結「IPv6: Linux as 6to4 host」),最後是用「IPv6 6to4 config generator for Debian」這邊的方法。我是用 Ubuntu 12.04。

/etc/network/interface 裡加上:

auto tun6to4
iface tun6to4 inet6 v4tunnel
	address 2002:0102:0304::1 
        netmask 16              
	gateway ::192.88.99.1
	endpoint any
	local 1.2.3.4

其中 1.2.3.4 是 public IP,而 0102:0304 則是 hex 表示法。設完後跑 ifup tun6to4 就會帶起來了。

可以用 telnet -6 www.google.com 80 看看有沒有通,或是連到 The KAME project 看看有沒有會動的烏龜 :p

BT Retail 開始實際測試 CGNAT...

英國的 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)

ISP 架設 NAT 解決 IPv4 不夠的問題...

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

Facebook 將繼續提供 IPv6 的服務...

World IPv6 Day 結束了,結束後第一個看到公告的是 Facebook 在「Exciting Results from World IPv6 Day」提到的:

Based on the encouraging results, we’ve decided to leave our Developer site dual-stacked, supporting both IPv4 and IPv6. And we will continue to adapt our entire code base and tools to support IPv6.

也就是 developers.facebook.com 仍然會保留 IPv6 & IPv4 位置:

developers.facebook.com
developers.facebook.com. 30 IN AAAA 2620:0:1c00:0:face:b00c:0:7

不過這次 World IPv6 Day 以 Facebook 的量也才看到 1 million users 啊...

另外觀察到 www.limelightnetworks.com 還繼續有 IPv6 服務:

www.limelightnetworks.com. 128 IN CNAME llnw.vo.llnwd.net.
llnw.vo.llnwd.net. 257 IN AAAA 2402:6800:720:11:230:48ff:fed9:f114
llnw.vo.llnwd.net. 257 IN AAAA 2402:6800:720:11:230:48ff:fe8d:aa74

另外這個比較特別,不確定是還沒拔掉還是決定要繼續跑:

www.hinet.net. 300 IN AAAA 2001:b000:180:3::7

World IPv6 Day

預定在 6/8 舉辦的 World IPv6 Day 快要到了,因為是以 UTC 時間來算,所以換算成台灣的時間,是早上八點開始。在「Participating websites」有列出參與的站台以及會使用的 domain (也就是直接加上 AAAA record)。

可以看到 Google 是拿 www.google.com 以及 www.youtube.com 出來參戰,Facebook 也會將 www.facebook.com 參與。

這樣已經很大沒錯,但另外一個重點是 YouTube 的 video data 本身有沒有打算要上這一波的測試。

另外剛剛發現 HiNet 已經建立了自己的 192.88.99.1 anycast address 負責 6to4 (nopa.tw/45),而 TWGate 則是透過香港的 Hurricane Electric 轉。

另外兩家大的 ISP 就不提了,都是 Hurricane Electric 在美西的點...

IPv6 的進展,以及北美 IPv4 流量分析...

Arbor Networks 的 Blog 上分析了目前 IPv6 的進展:「Six Months, Six Providers and IPv6」。

以去年八月到今年二月的數字來看,其實現在 P2P 還是佔絕對性的數量:

另外一張圖是北美 IPv4 的頻寬分析,這點可以看出之前 Netflix 另外採購 Level3 的 CDN 對 Akamai 的影響:

這數字真驚人...

APNIC 手上的 IPv4 address 用完了...

亞太區 APNIC 手上的 IPv4 位置也分完了:「Asia Runs Out of IPv4 Addresses」。

也就是說,要跟 APNIC 拿 IPv4 address 沒得拿了,要 IPv4 address 得跟現有的這些人買,不然就得想辦法跨區要。

這個消息對今年兩個月後的 IPv6 測試有更高的期望了...

Linode 總算是去申請 IPv6 位置了...

有人在 Linode 的 forum 上提到 Linode 去申請了 IPv6 位置:「NET6-2600-3C00-1」,一個超大的 /30 耶...

不過 Linode 的 staff 也出來說,目前還沒有 ETA,請大家再等等... 再等幾個月看看吧?有 native IPv6 總是比較痛快...

IPv4 分配完畢,進入下一階段...

前陣子 IPv4 倒數第六個 /8 被分給 APNIC 後,觸發了 IPv4 最後五個 /8 的分發機制,自動將剩下的五個 /8 分給每個 RIR:「Two /8s allocated to APNIC from IANA」。

IPv4 全部分配出去後,一般的使用者還感覺不到 IPv4 耗盡的問題,接下來的一至兩個月都還有機會從 RIR 手上申請到 IPv4 address。

在「IPv6 transition mechanisms」這邊列有各種 IPv4 轉移到 IPv6 時的過渡方案,有一些方案已經有硬體支援。(像是 Juniper 的 NAT64:「Configuring Stateful NAT64 for Handling IPv4 Address Depletion」)

六月的 IPv6 測試...

今年 6/8 將會有超大的 IPv6 測試:「World IPv6 Day has Facebook, Google & Yahoo Support」。

包括 FacebookGoogleYahoo 都會上線測試,另外最大的兩個 CDN 業者 AkamaiLimelight Networks 也都會上線測試。

雖然沒有說明細節,但猜測這次的 IPv6 測試應該是將 Facebokk 的 www.facebook.com、Google 的 www.google.com,以及 Yahoo 的 www.yahoo.com 直接增加 AAAA record (也一樣保留 A record),然後看看結果如何。而 Akamai 與 Limelight Networks 應該是配合有意願的客戶上線測試。

以目前看起來,6/8 的測試會是一個「開始」,這次的測試不會有結束的時候,藉機順便轉換到 IPv6 上。剛好借測試的名義打破雞蛋問題。Google 的測試不知道會不會將 YouTube 部份影片丟上來測,這對 IPv6 的轉移會影響很大:如果 IPv6 bandwidth 夠大,就會有更多 ISP 會建立 IPv6 的環境。

大多數人沒有 native IPv6 環境,多是透過 tunnel 之類的環境使用 IPv6 (尤其是 192.88.99.1 這組 Anycast-based 的 6to4 tunnel)。可以預期到時候會讓使用量衝上去許多...