Teredo隧道
 | 此條目翻譯自其他語言維基百科，需要相關領域的編者協助校對翻譯。 |
 | 此條目已列出參考資料，但文內引註不足，部分內容的來源仍然不明。 (2018年8月25日) |
Teredo是一個IPv6轉換機制，它可為運行在IPv4互聯網但沒有IPv6網絡原生連接的支持IPv6的主機提供完全的連通性。與其他的類似協議不同，它可以在網絡地址轉換（NAT）設備（例如家庭路由器）後完成功能。
Teredo使用跨平台隧道協議提供IPv6連通性，將IPv6資料包封裝在IPv4用戶數據報協議（UDP）數據包內。Teredo路由器將這些數據報在IPv4互聯網上傳輸及通過NAT設備。其他在IPv6網絡上的Teredo節點（被稱為Teredo中繼，英文為Teredo relays）接收數據包，解開它們的封裝，以及傳遞它們。
Teredo是一種臨時措施。在長遠的未來，所有IPv6主機都應該使用原生的IPv6連接。Teredo應在原生IPv6連接可用時被停用。Christian Huitema在微軟開發了Teredo，並且互聯網工程任務組（IETF）將其標準化為RFC 4380。Teredo服務器監聽UDP端口3544。
目的[編輯]
6to4，最常用的IPv6通過IPv4的隧道協議，但它需要隧道端點有一個公網IPv4地址。然而，許多主機目前通過一個或多個NAT設備來連接IPv4互聯網，原因之一是IPv4位址枯竭。在這種情況下，只有NAT設備有IPv4地址，6to4隧道端點必須在NAT設備上被實現。出於技術或經濟原因，目前已被部署的許多NAT設備無法升級為實現6to4。
Teredo通過在UDP/IPv4數據包內封裝IPv6數據包來緩解這個問題，大多數NAT可以正確轉發此種流量。這樣一來，NAT後的IPv6感知主機可以作為Teredo隧道端點，即使它沒有專用的公網IPv4地址。實際上，一個實現Teredo的主機可以在沒有本地網絡環境合作的條件下獲得IPv6連通性。
從長遠來看，所有IPv6主機都應該使用原生IPv6連接。臨時性的Teredo協議包含「落幕程序」規定：Teredo實現應該提供一個方法在當IPv6成熟並且使用一個非脆弱的連通機制時停止Teredo連接的使用。根據IETF89，微軟計劃在2014年上半年停用他們為Windows準備的Teredo服務器，並鼓勵停用公共運行的Teredo中繼。
概述[編輯]
- 有關完整解釋見外部連結中的Teredo概述。
Teredo協議執行幾種功能：
- 診斷UDP通過IPv4（UDPv4）的連通性並發現當前的NAT種類（使用STUN協議的簡化版）
- 為每個使用它的主機分配一個全局可路由的唯一IPv6地址
- 將IPv6數據包封裝在UDPv4數據報中以通過IPv4網絡傳輸（包括NAT穿透）
- 在Teredo主機與原生（或其他非Teredo）IPv6主機之間路由流量
節點類型[編輯]
Teredo定義了幾種不同類型的節點：
- Teredo客戶端
- 一個在NAT後具有IPv4互聯網連接的主機，並且使用Teredo隧道協議來訪問IPv6互聯網。Teredo客戶端被以Teredo前綴 (
2001::/32) 為開頭分配一個IPv6地址。[1]
- Teredo服務器
- 一個眾所周知的主機，用於初始化Teredo隧道的配置。Teredo服務器從不轉發任何客戶端的流量（除了IPv6 ping），因此有着適度的帶寬限制（大多是每個客戶端幾百位元每秒）[來源請求]，單台服務器就可以支持許多客戶端。此外，Teredo服務器可以用完全無狀態的方式實現，因此無論支持多少客戶端，它都只占用同樣的內存。
- Teredo中繼
- Teredo隧道的遠端。Teredo中繼必須代表它服務的Teredo客戶端轉發所有數據，但Teredo客戶端直接到Teredo客戶端的交換除外。因此，一個中繼需要大量的帶寬，並且只能同時支持有限數量的客戶端。每個Teredo中繼服務一定範圍內的IPv6主機（例如單個校園/公司，單個互聯網服務供應商或整個運營商網絡，或甚至整個IPv6互聯網）；它在任何Teredo客戶端與任何所述範圍內的主機間轉發流量。
- Teredo特定主機中繼
- 此種Teredo中繼只服務於運行它的主機。因此，它沒有特別的帶寬或路由要求。具有特定主機中繼的計算機使用Teredo與其他Teredo客戶端通信，但繼續用其主IPv6網絡提供與其他IPv6互聯網的連接。
IPv6地址[編輯]
每個Teredo客戶端被分配一個公共IPv6地址，其構造如下（高階位編號為0）：
- 位0至31保持Teredo前綴（2001::/32）。
- 位32至63嵌入要使用的Teredo服務器的IPv4主地址。
- 位64至79保持一些標記位及其他比特。這16位的格式為：首先是MSB——「CRAAAAUG AAAAAAAA」。「C」位，如果Teredo客戶端位於一個錐形NAT後面則設為1，否則為0，但RFC 5991將它改為始終為0，以避免向陌生人暴露此情況。「R」位目前未分配，應該設為0發送。「U」和「G」位設為0以模擬MAC地址中的「通用/本地」和「組/個人」位。前十一個「A」位為隨機值，第十二個「A」位在原RFC 4380規範中為0，但在RFC 5991中更改為由Teredo客戶端選擇的隨機位，以額外保護Teredo避免基於IPv6的掃描攻擊。
- 位80至95包含混淆後的UDP端口號。這是NAT映射給Teredo客戶端的端口號，將所有比特翻轉。
- 位96至127包含混淆後的IPv4地址。這是NAT的公網IPv4地址，將所有比特翻轉。
Teredo IPv6地址表
| 位 | 0 - 31 | 32 - 63 | 64 - 79 | 80 - 95 | 96 - 127 |
|---|---|---|---|---|---|
| 長度 | 32位 | 32位 | 16位 | 16位 | 32位 |
| 描述 | 前綴 | Teredo 服務器IPv4 |
標記 | 混淆的 UDP端口 |
混淆的客戶端 公網IPv4 |
舉例來說，IPv6地址2001:0000:4136:e378:8000:63bf:3fff:fdd2就是通過一個Teredo中繼：
- 使用地址為65.54.227.120的Teredo地址（十六進制的4136e378）
- 在錐形NAT後面，並且客戶端不完全兼容RFC 5991（設置了第64比特）
- 很可能（99.98%）不兼容RFC 5991（12個隨機位均為0，在兼容時的發生概率小於0.025%）
- 使用其NAT映射的40000端口（十六進制取反（not）63bf等於9c40，即十進制數字40000）
- NAT公共IPv4地址192.0.2.45（取反3ffffdd2等於c000022d，這就變成了192.0.2.45）
Teredo IPv6示例表
| 位 | 0 - 31 | 32 - 63 | 64 - 79 | 80 - 95 | 96 - 127 |
|---|---|---|---|---|---|
| 長度 | 32位 | 32位 | 16位 | 16位 | 32位 |
| 描述 | 前綴 | Teredo 服務器IPv4 |
標記 | 混淆的 UDP端口 |
混淆的客戶端 公網IPv4 |
| 部分 | 2001:0000 | 4136:e378 | 8000 | 63bf | 3fff:fdd2 |
| 解碼後 | 65.54.227.120 | 錐形NAT | 40000 | 192.0.2.45 |
服務器[編輯]
- 有關現有Teredo服務器的列表，見外部連結中的列表。
Teredo客戶端使用Teredo服務器通過簡化的類STUN「鑑別流程」檢測客戶端是否在任何類型的NAT後面。Teredo客戶端也通過定期發送UDP數據包來維護其NAT上對其Teredo服務器的綁定，這樣確保服務器始終可以聯繫到其客戶端——NAT打孔正常工作的必要條件。
如果一個Teredo中繼（或另一個Teredo客戶端）必須發送一個IPv6數據包到一個Teredo客戶端，它首先發送一個Teredo氣泡（bubble）包到客戶端的Teredo服務器（根據Teredo客戶端的Teredo IPv6地址推算）。然後服務器轉發「氣泡」包到客戶端，使Teredo客戶端軟件了解它必須打孔到Teredo中繼。
Teredo服務器也可以將Teredo客戶端的ICMPv6包傳輸到IPv6互聯網。在實踐中，當一個Teredo客戶端想聯繫一個原生IPv6節點，它必須定位相應的Teredo中繼——即公網IPv4和UDP端口號，以發送封裝的IPv6包。為做到此目的，客戶端製作一個傳往IPv6節點的ICMPv6 Echo請求（ping），並經它配置的Teredo服務器發送。Teredo服務器解開封裝並將ping傳往IPv6互聯網，使ping最終抵達IPv6節點。IPv6節點應該在收到ICMPv6 Echo回復後按照RFC 2460應答。這個應答包首先被路由到最近的Teredo中繼，然後逐步抵達與其聯繫的Teredo客戶端。
維護一個Teredo服務器所需的帶寬很少，因為它們不參與IPv6數據包的實際發送與接收。另外，它不涉及對互聯網路由協議的任何訪問。Teredo服務器的必備條件僅有：
- 可以發出源地址屬於Teredo前綴的ICMPv6數據包
- 兩個不同的公網IPv4地址。雖然這沒有寫在官方的規範中，但微軟Windows客戶端期望兩個連續的地址——第二個IPv4地址用於NAT檢測
公共Teredo服務器：
- teredo.remlab.net / teredo-debian.remlab.net (德國)
- teredo.ngix.ne.kr (韓國)
- teredo.managemydedi.com (美國芝加哥)
- teredo.trex.fi (芬蘭)
- win8.ipv6.microsoft.com (隱藏於Windows RT 8.1中的Teredo服務器)，Windows 7中不存在。
- win10.ipv6.microsoft.com （Windows10中的Teredo服務器）
中繼[編輯]
Teredo中繼可能需要大量的網絡帶寬。另外，它必須輸出（宣告）Teredo IPv6前綴（2001::/32）到其他IPv6主機。這樣之後，Teredo中繼就能收到其他尋址到Teredo客戶端的IPv6主機的流量，然後通過UDP/IPv4轉發它們。與此對應，它會收到其他通過UDP/IPv4尋址到IPv6主機的Teredo客戶端發來的數據包，將這些數據包注入到IPv6網絡。
在實踐中，網絡管理員可以設置一個只服務於他們公司或校園的私有Teredo中繼。這可以為他們的IPv6網絡與任何Teredo客戶端提供一個短途路徑。但是，在超過單個網絡的規模上設置一個Teredo中繼需要輸出BGP IPv6路由到其他自治系統（AS）的能力。
不同於6to4，連接中的兩個端點可以使用不同的中繼，在原生IPv6主機與一個Teredo客戶端之間的流量使用同一個Teredo中繼，即最靠近原生IPv6主機網絡側的那個。Teredo客戶端不能自己定位一個中繼，因為它不能自己發送IPv6數據包。如果它需要啟動與一個原生IPv6主機的連接，它首先通過Teredo服務器使用客戶端的Teredo IPv6地址發送一個數據包到原生IPv6主機。原生IPv6主機之後照常響應客戶端的Teredo IPv6地址，這能使數據包最終找到Teredo中繼，從而啟動與客戶端的連接（可能使用Teredo服務器進行NAT打孔）。Teredo客戶端和原生IPv6主角之後使用中繼進行通信，只要它們需要。此設計意味着Teredo服務器與客戶端都不需要知道任何Teredo中繼的IPv4地址。它們通過全局IPv6路由表自動找到合適的路由，因為所有Teredo中繼都宣告網絡2001::/32。
- 有關Teredo和BGP上的近實時信息見外部連結。
2006年3月30日，意大利ISP ITGate是第一個在其IPv6互聯網上宣告到2001::/32的路由的AS，這使RFC 4380兼容的Teredo實現有望充分可用。但截至2007年2月16日，它已不再有效。
2009年第一季度，IPv6骨幹Hurricane Electric使用任播技術啟用了14個Teredo中繼[2]並全局性宣告2001::/32。這些中繼分別位於西雅圖、弗里蒙特、洛杉磯、芝加哥、達拉斯、多倫多、紐約、Ashburn、邁阿密、倫敦、巴黎、阿姆斯特丹、法蘭克福和香港。
預計大型網絡運營商將維護Teredo中繼。與6to4一樣，仍不清楚如果大部分互聯網主機通過基於IPv4的Teredo使用IPv6，Teredo將會如何擴展[需要解釋]。雖然微軟自發布用於Windows XP的Teredo偽隧道以來運行有一組Teredo服務器，但他們從未為IPv6互聯網整體提供Teredo中繼服務。
限制[編輯]
Teredo不兼容所有NAT設備。根據RFC 3489的術語，它支持全錐、受限和端口受限的NAT設備，但不支持對稱NAT。最初的Shipworm規範製作的最終版Teredo協議也支持對稱NAT，但最終由於安全考慮而放棄。[3]
台灣的國立交通大學之後提出了SymTeredo，這增強了原有的Teredo協議以支持對稱NAT，並且微軟和Miredo的實現實施了某些的未規定、非標準的擴展以改進對對稱NAT的支持。[4]但是在對稱NAT後的Teredo客戶端與在對稱NAT或端口限制NAT後的Teredo客戶端的連通似乎仍然不可能。[來源請求]
另外，Teredo假設兩個客戶端交換封裝的IPv6數據包時，他們使用的映射/外部的UDP端口號與他們聯繫Teredo服務器（以及建立Teredo IPv6地址）的端口號相同。若無此假設，兩個客戶端直接不可能建立直接通信，從而中繼不得不進行三角形路由。一個Teredo實現嘗試在啟動時檢測NAT類型，並且如果NAT看起來對稱，則拒絕運作。（此限制有時可以在NAT設備上配置轉發規則來解決，但這需要NAT設備的管理權限。）[來源請求]
Teredo只能為每個隧道端點提供一個IPv6地址。因此，不能使用一個Teredo隧道連接多個主機[需要解釋]，這不同於6to4和某些點對點IPv6隧道。所有Teredo客戶端與IPv6互聯網的可用帶寬都受到Teredo中繼可用資源的限制，這與6to4等中繼沒什麼區別。
備選方案[編輯]
6to4需要一個公網IPv4地址，但為每個隧道端點提供一個較大的48位IPv6前綴，並有較低的封裝頭。點對點隧道可能比Teredo更可靠和負責，並且提供永久IPv6地址通常不依賴於隧道端點的IPv4地址。部分點對點隧道中間人（Tunnel broker）也支持UDP封裝以穿透NAT（例如AYIYA協議可以做到）。但反過來說，點對點隧道通常需要註冊。自動化工具（例如AICCU）可以簡化使用點對點隧道的流程。
安全事項[編輯]
暴露[編輯]
Teredo分配全局可路由的IPv6地址使NAT設備後的網絡主機增加了攻擊面，因為如不這樣做則無法被互聯網訪問。因為這樣做，Teredo潛在地將任何啟用IPv6並開放端口到外部的應用程序暴露在外。Teredo隧道的封裝可以隱蔽IPv6數據流量的內容，防止數據包檢測乃至部分IPv4惡意軟件的傳播。[5]US CERT已發表一篇論文，論述使用IPv6隧道的惡意軟件風險。[5]Teredo也將IPv6棧和隧道軟件暴露給攻擊者，如果它們被發現存在任何遠程可利用的漏洞，這可能變得危險。
微軟IPv6棧有一個「保護等級」套接字選項。這允許應用程序指定它們是否願意處理出自Teredo隧道的流量，任何非Teredo隧道的流量（默認設置），或者只接收本地內部網的流量。
Teredo協議也在數據包中封裝有關隧道端點的詳細信息。[6]
防火牆、過濾和阻止[編輯]
為使Teredo偽隧道正常工作，發出的UDP數據包不能被過濾。此外，對這些數據包的回覆（即回傳的流量）也不能被過濾。這取決於NAT的典型設置及其有狀態防火牆的功能。如果外發的IPv4 UDP流量被攔截，Teredo隧道軟件會檢測到致命錯誤並停止。另外，如果攔截外發值3544端口的UDP流量可能會干擾Teredo的活動。
通過路由環路DoS[編輯]
在近期，一種新的使用Teredo隧道利用路由環路製造拒絕服務攻擊已被發現。這相對容易預防。[7]
默認啟用[編輯]
微軟操作系統的當前版本已啟用IPv6過渡技術，包括默認啟用Teredo。如果IPv6未在公司網絡上實現，可以通過命令行提示符、註冊表編輯或使用組策略禁用這些過渡技術。由於微軟默認啟用，如果需要避免IPv6啟用狀態下的新安全威脅，管理員需要明確配置Windows操作系統中的和相關過渡技術。[8]
實現[編輯]
Teredo目前有多種實現可用：
- Windows XP SP2包括一個客戶端和特定主機中繼（Service Pack 1的Advanced Networking Pack中也可用）。
- Windows Server 2003有一個微軟Beta計劃提供的中繼和服務器。
- Windows Vista和Windows 7使用一個未指明的擴展內置了對對稱NAT穿透的Teredo支持。但是，如果只有一個本地鏈路和Teredo地址存在，那麼這些操作系統在DNS A記錄存在時不會嘗試解析IPv6 DNS AAAA記錄，因此會使用IPv4。在這種情況下，只能訪問明確指定的IPv6地址。 在此種情況下，在註冊表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache\Parameters中添加一個DWORD值：AddrConfigControl = 0才能使Teredo隧道激活（被默認使用），達到連向IPv6的目的。
- Miredo是一個適用於Linux、*BSD和Mac OS X的客戶端、中繼和服務器。
- ng_teredo是一個基於netgraph的適用於FreeBSD的中繼和服務器，出自LIP6大學和6WIND。[9]
- NICI-Teredo是一個適用於Linux內核的中繼和一個用戶級Teredo服務器，由國立交通大學開發。[10]
名稱由來[編輯]
Teredo隧道協議的最初暱稱為shipworm（船蛆）。該想法來自該協議將穿過NAT設備，很像船蟲穿過木頭上的隧道。Shipworms是造成很多木殼船損壞的成因，但Christian Huitema在原始草案中指出：「該種動物只在相對乾淨且未受污染的水中生存，它最近在幾個北美港口的復出也證明這與清潔相關。與此類似，通過穿透NAT，該服務將有助於達到新的互聯網透明度。」
Christian Huitema後將名稱改為Teredo以避免將它與電腦蠕蟲混淆。[11]Teredo navalis（船蛆）是一種著名的船蟲種類的拉丁名。
參考資料[編輯]
- ^ Teredo Addresses (Windows). msdn.microsoft.com. [2016-12-22]. （原始內容存檔於2016-12-23） （英語）.
- ^ Levy, Martin. Hurricane Electric's experience in deploying Teredo and 6to4 relays (PDF). LACNIC-XII/FLIP6 2009 Conference, Panama City, Panama. May 28, 2009 [2016-12-22]. （原始內容存檔 (PDF)於2015-04-11）.
- ^ Shipworm: Tunneling IPv6 over UDP through NATs. [2016-12-22]. （原始內容存檔於2016-03-03）.
- ^ Huang, Shiang-Ming; Wu, Quincy; Lin, Yi-Bing. Enhancing Teredo IPv6 tunneling to traverse the symmetric NAT. IEEE Communications Letters. 2006-05, 10 (5) [2023-04-18]. ISSN 1558-2558. doi:10.1109/LCOMM.2006.1633339. （原始內容存檔於2019-06-29）.
- ^ 5.0 5.1 Malware Tunneling in IPv6 | US-CERT. [2016-12-22]. （原始內容存檔於2016-12-08）.
- ^ IPv6 Tunneling Protocols: Good for Adoption, Not So Hot for Security - TrendLabs Security Intelligence Blog. 2009-10-26 [2016-12-22]. （原始內容存檔於2016-10-08） （美國英語）.
- ^ Gont, Fernando. Internet-Draft - Teredo routing loops - Mitigating Teredo Rooting Loop Attacks. ietf.org: 2. September 8, 2010 [2016-12-22]. （原始內容存檔於2017-05-09）.
- ^ Perschke, Susan. Hackers target IPv6. [2016-09-05]. （原始內容存檔於2016-09-11）.
- ^ Kabassanov, Konstantin; Jardin, Vincent.
- ^ "Solomon, Aaron".
- ^ Huitema, Christian. (ngtrans) Renaming Shipworm as Teredo?. IETF ngtrans wg mailing list. December 19, 2001.[失效連結]
外部連結[編輯]
- Teredo概述（頁面存檔備份，存於網際網路檔案館），Microsoft TechNet提供（英文）
- 當前任播的Teredo BGP路由器（頁面存檔備份，存於網際網路檔案館）（英文）
- TEREDO-MNT（頁面存檔備份，存於網際網路檔案館）：通過BGP宣告Teredo前綴的運營商列表（英文）
- Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). RFC 4380, C. Huitema. February 2006.（英文）
- 基於JavaScript的Teredo-IP地址計算器（頁面存檔備份，存於網際網路檔案館）（英文）
| |||||||||||||||||||||||||||