本頁使用了標題或全文手工轉換

Teredo隧道

維基百科,自由的百科全書
跳到: 導覽搜尋

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英語Christian Huitema微軟開發了Teredo,並且互聯網工程任務組(IETF)將其標準化為RFC 4380。Teredo伺服器監聽UDP3544

目的[編輯]

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協定執行幾種功能:

  1. 診斷UDP通過IPv4(UDPv4)的連通性並發現當前的NAT種類(使用STUN協定的簡化版)
  2. 為每個使用它的主機分配一個全局可路由的唯一IPv6地址
  3. 將IPv6封包封裝在UDPv4數據報中以通過IPv4網絡傳輸(包括NAT穿透
  4. 在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」位設為1,如果Teredo用戶端位於一個錐形NAT後面,否則為0;但RFC 5991將它改為始終為0以避免向陌生人暴露此情況。「R」位目前未分配,應該設為0傳送。「U」和「G」位設為0以模擬MAC地址中的「通用/本地」和「組/個人」位。第十二個「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打孔英語NAT hole punching正常工作的必要條件。

如果一個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,但最終由於安全考慮而放棄。

台灣的國立交通大學之後提出了SymTeredo,這增強了原有的Teredo協定以支援對稱NAT,並且微軟和Miredo的實現實施了某些的未規定、非標準的擴充功能以改進對對稱NAT的支援。但是在對稱NAT後的Teredo用戶端與在對稱NAT或埠限制NAT後的Teredo用戶端的連通似乎仍然不可能。[來源請求]

另外,Teredo假設兩個用戶端交換封裝的IPv6封包時,他們使用的對映/外部的UDP埠號與他們聯繫Teredo伺服器(以及建立Teredo IPv6地址)的埠號相同。若無此假設,兩個用戶端直接不可能建立直接通訊,從而中繼不得不進行三角形路由英語triangular routing。一個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惡意軟件的傳播。[3]US CERT已發表一篇論文,論述使用IPv6隧道的惡意軟件風險。[3]Teredo也將IPv6棧和隧道軟件暴露給攻擊者,如果它們被發現存在任何遠端可利用的漏洞,這可能變得危險。

微軟IPv6棧有一個「保護等級」通訊端選項。這允許應用程式指定它們是否願意處理出自Teredo隧道的流量,任何非Teredo隧道的流量(預設設定),或者只接收本地內聯網的流量。

Teredo協定也在封包中封裝有關隧道端點的詳細資訊。[4]

防火牆、過濾和阻止[編輯]

為使Teredo偽隧道正常工作,發出的UDP封包不能被過濾。此外,對這些封包的回覆(即回傳的流量)也不能被過濾。這取決於NAT的典型設定及其有狀態防火牆的功能。如果外發的IPv4 UDP流量被攔截,Teredo隧道軟件會檢測到致命錯誤並停止。另外,如果攔截外發值3544埠的UDP流量可能會干擾Teredo的活動。

通過路由環路DoS[編輯]

在近期,一種新的使用Teredo隧道利用路由環路製造拒絕服務攻擊已被發現。這相對容易預防。[5]

預設啟用[編輯]

微軟作業系統的目前版本已啟用IPv6過渡技術,包括預設啟用Teredo。如果IPv6未在公司網絡上實現,可以通過命令列提示符、登錄檔編輯或使用組策略禁用這些過渡技術。由於微軟預設啟用,如果需要避免IPv6啟用狀態下的新安全威脅,管理員需要明確配置Windows作業系統中的和相關過渡技術。[6]

實現[編輯]

Teredo目前有多種實現可用:

  • Windows XP SP2包括一個用戶端和特定主機中繼(Service Pack 1的Advanced Networking Pack中也可用)。
  • Windows Server 2003有一個微軟Beta計劃提供的中繼和伺服器。
  • Windows VistaWindows 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*BSDMac OS X的用戶端、中繼和伺服器。
  • ng_teredo是一個基於netgraph英語netgraph的適用於FreeBSD的中繼和伺服器,出自LIP6英語Laboratoire d'Informatique de Paris 6大學和6WIND。[7][來源請求]
  • NICI-Teredo是一個適用於Linux內核的中繼和一個用戶級Teredo伺服器,由國立交通大學開發。[8][來源請求]

名稱由來[編輯]

Teredo隧道協定的最初暱稱為shipworm(船蛆)。該想法來自該協定將穿過NAT裝置,很像船蟲穿過木頭上的隧道。Shipworms是造成很多木殼船損壞的成因,但Christian Huitema在原始草案中指出:「該種動物只在相對乾淨且未受污染的水中生存,它最近在幾個北美港口的復出也證明這與清潔相關。與此類似,通過穿透NAT,該服務將有助於達到新的互聯網透明度。」

Christian Huitema後將名稱改為Teredo以避免將它與電腦蠕蟲混淆。[9]Teredo navalis(船蛆)是一種著名的船蟲種類的拉丁名。

參考資料[編輯]

  1. ^ Teredo Addresses (Windows). msdn.microsoft.com (英語). 
  2. ^ Levy, Martin. Hurricane Electric's experience in deploying Teredo and 6to4 relays (PDF). LACNIC-XII/FLIP6 2009 Conference, Panama City, Panama. May 28, 2009. 
  3. ^ 3.0 3.1 Malware Tunneling in IPv6 | US-CERT. 
  4. ^ IPv6 Tunneling Protocols: Good for Adoption, Not So Hot for Security - TrendLabs Security Intelligence Blog. 2009-10-26 (美國英語). 
  5. ^ Gont, Fernando. Internet-Draft - Teredo routing loops - Mitigating Teredo Rooting Loop Attacks. ietf.org: 2. September 8, 2010. 
  6. ^ Perschke, Susan. Hackers target IPv6. [2016-09-05]. 
  7. ^ Kabassanov, Konstantin; Jardin, Vincent.
  8. ^ "Solomon, Aaron".
  9. ^ Huitema, Christian. (ngtrans) Renaming Shipworm as Teredo?. IETF ngtrans wg mailing list. December 19, 2001. 

外部連結[編輯]