TANet 6to4 服務與路由之改善 服務與路由之改善 服務與路由之改善 服務與路由之改善
張瑛杰 張瑛杰
張瑛杰 張瑛杰
1蔡尚修 蔡尚修 蔡尚修 蔡尚修
2吳坤熹 吳坤熹 吳坤熹 吳坤熹
1南投區網
南投區網 南投區網
南投區網
1麟瑞 麟瑞 麟瑞 麟瑞科技 科技 科技 科技
2{ycc, solomon}@ncnu.edu.tw
1hugh_tsai@ringline.com.tw
21 摘要 摘要 摘要 摘要
在 IPv4 至 IPv6 的轉移機制中，6to4 全自動的 通道機制是極受歡迎的一項，並且在 Windows，
Linux，FreeBSD 等作業系統中均已內定支援。然而 以 TANet 現狀為例，6to4 的主機與 IPv6 網路間的 通訊呈現路由不對稱的現象，導致 6to4 使用者欲連 上國內的 IPv6 主機，封包來回需要 200ms 以上。
本文中分析其癥結並提出改善之道，最後配合在南 投區網的實作，有效將原本 200ms 的傳輸延遲減低 至 10ms。
關鍵詞 關鍵詞關鍵詞
關鍵詞：六到四通道、任意播送、轉運路由器、路 徑最佳化
2 Abstract
The automatic 6to4 tunnel is a popular transition mechanism for IPv4/IPv6 migration. It is widely supported in many operating systems including Windows, Linux, and FreeBSD. However, currently in TANet, the routing between 6to4 hosts and native IPv6 networks is asymmetric. The packet sent from a 6to4 host may be detoured to the US before it comes back to reach an IPv6 hosts in Taiwan, so sometimes the round-trip time may become longer than 200ms.
In this paper, we analyze the issue and propose a problem. By implementing the solution in Nantou Regional Center, the 200ms delay is efficiently reduced to 10ms.
Keywords: 6to4 tunnel, anycast, relay router, route optimization
1. 前言 前言 前言 前言
網際網路通訊協定（Internet Protocol，簡稱 IP）
的靈魂是 IP 位址。每個連上網路的設備，都擁有一 個像 140.112.172.1 這樣的位址。這個位址是全世界 獨一無二的。只要指定一部設備的 IP 位址，不管它 在哪個國家，不管它使用乙太網路、光纖、或是有 線無線的各種上網方式，Internet 都知道如何正確地 把資料送往正確的目的地。這使得網路上的應用程 式開發變得十分單純，也因此成就了「網路無國界」
的現代傳奇。
然而由於一開始設計上的疏忽，沒有預料到 Internet 成長如此快速，IP 位址已經面臨匱乏的窘 境。目前所通用的 Internet Protocol，是所謂的第四 版，一般稱為 IPv4，其位址的長度為 32 位元。即
使有效地使用，總數也不過 40 億左右。相較於目 前全世界人口總 69 億[1]，顯然不足以分配給每人 一個 IP 位址。而當未來人們不僅使用個人電腦上 網，甚至使用智慧型手機、網路家電等設備上網 時，對 IP 位址的需求又將擴大。今年二月間，負責 分 配 全 球 IP 位 址 的 IANA （ Internet Assigned Numbers Authority），將全球最後五個/8 的位址區塊 分發給五大洲的區域註冊中心後，舊有的 IPv4 位址 不足的狀況，可說就亮起了紅燈。原本一般預測約 在半年後，經濟成長速度最快的亞太地區就會將這 段分配到的/8 耗盡，但在四月中亞太區的區域註冊 中 心 APNIC （ Asia-Pacific Network Information Center）就宣告其「庫存」的 IPv4 位址已全數發放 完畢，亞太地區位址枯竭的時期正式來臨[2]。
既然已難以再申請到 IPv4 位址的配發，因此 新版的 Internet 協定（Internet Protocol Version 6，簡 稱 IPv6），自然就成為建立新網路以及服務時的主 要選擇。如何讓現有的 IPv4 網路順利轉移至 IPv6，
也就成了網路技術人員關心的重點。
根 據 Internet 工 程 工 作 小 組 （ Internet Engineering Task Force，簡稱 IETF）的建議，IPv4 至 IPv6 的轉移機制，可以分為三個方面[3]：
1. Dual Stack：網路設備軟體上同時支援 IPv4 與 IPv6，不需增加硬體投資。
2. Tunneling：兩個 IPv6 網路即使沒有直接相 連，也可將 IPv6 封包裝在 IPv4 標頭中，利 用現有的 IPv4 網路送達目的地。
3. Translation：當 IPv6 普及後，未來將有設備 基於成本考量，僅支援 IPv6，而不支援 IPv4。此時若仍有舊的設備僅支援 IPv4，
兩者就無法溝通，需藉助轉換器進行 IPv4 與 IPv6 封包格式的轉換。
目前大多數電腦設備的作業系統，如 Microsoft Windows、Linux、FreeBSD 等，均以 Dual Stack 的 方式同時支援 IPv4 及 IPv6。行動上網的設備如 Apple iPhone，在作業系統 iOS 4 起即支援 IPv4 和 IPv6；而 Android 手機也由 2.1 版起支援 IPv4/IPv6。
因此就使用者的上網設備而言，目前市面上主要的 產品多半都支援 IPv6。然而，上網的環境中，仍有 不少僅支援 IPv4。為了讓新的終端設備能順利與 IPv6網路上的設備通訊，Tunneling 就是一項快速有 效而成本低廉的做法。
在不需要更新網路設備的情況下，這些 Dual Stack的設備可以與遠端的 IPv6 設備（同樣為 Dual Stack）建立 Tunnel，然後利用現有的 IPv4 網路將 封包送達目的地。由於建立 Tunnel 的指令較複雜
（如圖 1），不熟練的使用者往往在參數設定上有誤 而造成 Tunnel 無法成功建立，因此後來就發展了 Tunnel Broker[4]。使用者只要先到網頁上登錄，
Tunnel Broker 就會產生一段命令檔，供使用者執 行。有些 Tunnel Broker 的服務業者如 gogoNET，
甚至讓使用者預先下載一支程式，執行時輸入帳號 密碼，就自動幫使用者修改設定建立 Tunnel。因此 這種半自動化的方式，頗受許多使用者的歡迎。然 而，許多人並不喜歡為了使用 IPv6 就必須多安裝一 個程式。此外，由於每家電信廠商所提供的 Tunnel Broker只認得它自家的 Tunnel Server，因此若你下 載的是歐洲的 Hurricane Electric 所提供的 Tunnel Broker，它將會指引你與位在歐洲的伺服器建立 Tunnel。即使你要通訊的對象近在台灣，也會繞遠 路 Tunnel 到歐洲再經由歐洲的 IPv6 網路將封包送 回台灣。為了解決上述問題，自動化的 6to4 Tunnel 機制就應運而生。
(a) Manually configured tunnel on a Cisco router
(b) Manually configured tunnel on Linux
(c) Manually configured tunnel on FreeBSD
(d) Manually configured tunnel on Windows 7 圖
圖 圖
圖 1 Manually configure a tunnel
2. 6to4 Tunnel
為了讓兩部 6to4 設備無須像圖 1 中的方法在事 前指定 Tunnel 兩端的 IPv4 位址，6to4 的設計為，
IPv6位址的前 16 位元固定使用十六進位的 2002，
接下來 32 位元為本機的 IPv4 位址。例如 IPv4 位址 若為 140.112.172.1，則 6to4 位址的前 48 位元將是 2002:8C70:AC01。如此一來，兩部 6to4 設備只要取 出對方 IPv6 位址中第 17 至第 48 位元，就可以得知 對方的 IPv4 位址，並據以動態建立 Tunnel，如圖 2 所示。不需像傳統手動設定的方法，要與一百部主 機建立 Tunnel，就必須下達一百次指令。藉由 6to4 自動化的機制，只要把介面設定好，之後不論要與 多少部 6to4 設備建立 Tunnel，都可以自動完成，在 管理上可說簡便許多。
圖 圖 圖
圖 2 自動由自動由自動由 6to4 位址中取得自動由 位址中取得位址中取得 IPv4 位址位址中取得 位址位址位址
在封包的傳遞上，若兩部設備均位於 TANet，
則會依 IPv4 現有的路由，走最短路徑抵達目的地，
不致於像 Tunnel Broker 會有繞遠路的情形。因此 6to4可以說是簡便而又快捷的 Tunnel 機制。唯一的 要求是，建立 Tunnel 的兩個端點均必須擁有 public IPv4位址。臺灣學術網路得天獨厚，許多早期加入 TANet的大學都坐擁 256 個/24（總數約為六萬五千）
的位址，連技職院校也有不少取得 40 個/24（約一 萬個）IPv4 位址，因此分配給每部電腦一個 public
IPv4位址並不成問題。反而在網路設備的支援上，
往往因為歷史的包袱，在校內許多區域尚不支援 IPv6。在這種情況下，6to4 就成為有意嘗試 IPv6 的 使用者「自力救濟」的絕佳選擇。
這套機制雖然可讓兩部 6to4 主機輕易互通，但 如果是一部不支援 6to4 的 IPv6 主機，它該如何與 6to4的主機通訊呢？就需要一台懂得6to4 的路由器 來 幫 它 轉 送 了 。 RFC 3056 定 義 了 6to4 relay router[5]，是一台 Dual Stack 的設備，同時具有 IPv4 與 IPv6 介面，並在 IPv4 介面上支援 6to4 Tunnel。
其 IPv6 介面會向 IPv6 網路宣傳（advertise）2002::/16 這個路由，所以 IPv6 網路中的節點，曉得如果要和 6to4設備（位址前 16 位元為 2002）進行通訊的話，
可以把封包發到這兒來轉送。每部 6to4 的主機，則 可以自行設定離它最近的 6to4 relay router（如圖圖圖圖 3），幫它把封包送入純 IPv6 的網路（Native IPv6 Network）中。
圖 圖圖
圖 3 Configure Your 6to4 Relay Router 為了進一步免除每個使用者設定所欲使用 6to4 relay router 的麻煩，RFC 3068 又定義了 192.88.99.1，作為 6to4 relay router 的 Anycast 位址 [6]。如此一來，使用者無須再做設定，即可利用 IPv4 Anycast自動找到網路上離他最近的 relay router，讓 6to4真正成為一個全自動的 Tunnel 機制。
然而，全自動的便利，必須建立在網路管理者 的妥善規劃上。日本的 KDDI 公司就曾在研究報告 中指出[7]，在使用者啟用 6to4 後，如果網路業者未 對應佈建 6to4 relay router，使用者經由 Anycast 找 到「最近」的 6to4 relay router 可能遠在美國。於是 當使用者要連上日本國內的 IPv6 網站時，反而連到 美國再繞遠路回來，封包傳送時間增加約 100ms，
於是就常會有「啟用 IPv6 後上網就變慢」的抱怨了。
在 TANet 的部份，中央大學在去年的 TANet 會議中也分享了 6to4 的建置經驗[8]。但實際使用 上，由 6to4 送往 IPv6 網路的封包雖然可由 Anycast 找到中央大學的 relay router 送出，但回來的封包卻 依然是經由美國繞回，形成不對稱的路由，以致 Round-Trip Time 高達 200ms。本文將以實例說明 TANet中各網路可如何建立其 6to4 服務，以提供使 用者一個快速且順暢的上網經驗。
3 TANet 6to4 路由現況 路由現況 路由現況 路由現況 3.1 6to4 架構 架構 架構 架構
位於 IPv4 網路的 6to4 用戶，如有一個 public IP 位址就可透過 6to4 的方式取得 IPv6 的連線。用戶
端會去尋找最近的 relay router(192.88.99.1)，經由 relay router與 IPv6 伺服器連線。
IPv6伺服器回應時也會尋找最近的 relay router(2002::/16)，再經由 relay router 與用戶端連 線。(如圖圖圖 4、圖圖 圖圖 5) 圖
圖 圖 圖
圖 4 6to4 → IPv6
圖 圖 圖
圖 5 IPv6 → 6to4
由圖圖圖 4及圖圖 圖圖 5，可看出 IPv4 用戶透過 6to4 與圖 IPv6伺服連線時，去回的封包並不一定會經過同一 台 relay router。
3.2 Relay Router 的重要性 的重要性 的重要性 的重要性
IPv4用戶與 IPv6 伺服器連線都必須經過 relay router，所以在 6to4 環境中 relay router 相當重要。
因此當 IPv4 用戶與 IPv6 伺服器透過 relay router 連 線時，中間經過的網路距離會影響 6to4 的連線品 質。例如：由 IPv4 用戶以 6to4 取得 IPv6 連線的能 力時，我們檢查由 IPv4 來 traceroute 192.88.99.1 (relay router)，發現回應時間小於 10ms(圖圖圖圖 6)，整個 連線品質相當不錯。這是由於該 relay router 建置於 學術網路內部，因此在國內只需花 10ms 即可抵達。
但 6to4 在實際連線時，用戶 traceroute 至同校園中 的 IPv6 伺服器卻發生連線品質下降至約 200ms 左 右(圖圖圖 7)。主要是因為在封包由 IPv6 伺服器送回到圖 6to4用戶時，IPv6 路由器不知如何處理 2002::/16 的封包，所以繞至國外 relay router
（2001:468:43F:3::2）所導致(圖圖圖圖 8)。
圖 圖圖
圖 6 6to4 → Relay Router
圖 圖 圖
圖 7 6to → Native IPv6
圖 圖圖
圖 8 IPv6 → 6to4
4 改善架構 改善架構 改善架構 改善架構
4.1 自行架設 自行架設 6to4 Relay Router 自行架設 自行架設
原有的網路架構 relay router 是由外單位來擔 任(圖圖圖 9)，所以會有許多地方是無法自行掌控的，圖 一旦發生連線品質不佳時也無法及時有效的去查 看問題與排除障礙。因此提出自行架設 relay router(圖圖圖圖 10)來確保連線品質。
圖圖圖
圖 9 6to4 Relay Router May Be Far Away
圖圖
圖圖 10 Build a Local Relay Router
4.2 路徑追蹤 路徑追蹤 路徑追蹤 路徑追蹤
經由在校園中自行架設 6to4 relay router 後，
IPv4用戶要去存取同單位的 IPv6 伺服器品質提升 許多，往返時間由原本的 200ms 減至小於 10ms(圖圖圖圖 11、圖圖圖圖 12、圖圖圖圖 13)，同時也發現由外部來存取本單 位的品質也由 300ms 提升至小於 40ms(圖圖圖圖 14)。
圖圖
圖圖 11 校內的校內的校內的校內的 6to4 Relay Router (192.88.99.1)
圖 圖 圖
圖 12 6to4 → IPv6 近多了近多了近多了近多了
圖 圖 圖
圖 13 IPv6 → 6to4 也抄近路了也抄近路了也抄近路了也抄近路了
圖 圖 圖
圖 14 6to4 Relay Router 啟用後之效能差異啟用後之效能差異啟用後之效能差異啟用後之效能差異
4.3 架設方式 架設方式 架設方式 架設方式
自行架設 6to4 並不困難，只要網路出口端路由 器具備 6to4 功能。下面是 Cisco Router 設定範例。
4.3.1 建立 6to4 Anycast Relay Service interface Loopback15
ip address 192.88.99.1 255.255.255.0 secondary ip address 163.22.15.254 255.255.255.0 no ip redirects
ipv6 address 2002:A322:1FD::1/128 ipv6 enable
4.3.2 建立 6to4 Tunnel interface Tunnel15
ipv6 address 2002:C058:6301::/128 anycast ipv6 enable
tunnel source Loopback15 tunnel mode ipv6ip 6to4 tunnel path-mtu-discovery 4.3.3 建立 2002::/16 路由
ipv6 route 2002::/16 Tunnel15
5 結論 結論 結論 結論
本文分析了 6to4 這項自動化的通道機制，並嘗 試解決目前在 TANet 上路由不對稱的問題。藉由調 整路由器的設定，可將原本使用者連至 IPv6 網路時 封包來回的往返時間由 200ms 降低至 10ms，有效 避免使用者在啟用 IPv6 後連線速度變慢的問題。
啟用 6to4 機制對路由器並未造成太大的負擔，
因此建議各區網中心均可建立此一服務，以嘉惠各 區域中之 6to4 使用者。
參考文獻 參考文獻 參考文獻 參考文獻
[1] Office of Population Research at Princeton University [http://opr.princeton.edu/popclock/]
[2] Steven J. Vaughan-Nichols, "Asia’s just run out of IPv4 Addresses", Ziff-Davis, April 14, 2011.
[3] E. Nordmark and R. Gilligan, “Basic transition mechanisms for IPv6 hosts and routers”, IETF RFC 4213, October 2005.
[4] 林民基, "IPv4轉移至 IPv6 – Tunnel Broker 服務介紹", 中央 研究院計算中心通訊電子報，Vol. 12, 2010.
[5] B. Carpenter and K. Moore, "Connection of IPv6 domains via IPv4 clouds", IETF RFC 3056, February 2001.
[6] C. Huitema, "An anycast prefix for 6to4 relay routers", IETF RFC 3068, June 2001.
[7] Y. Hei and K. Yamazaki, "Traffic analysis and worldwide operation of open 6to4 relays for IPv6 deployment", Proceedings of 2004 International Symposium on Applications and the Internet (SAINT 2004), pp.265-268.
[8] 王俊棠、王雅慈、曾黎明, “A IPv6 Aware/pass-thru NAT for Rapid Deployment and Transition”, Proceedings of the Taiwan Academic Network Conference (TANet 2010), Tainan, Taiwan.
