簡介
Teredo使用跨平台隧道協定提供IPv6連通性，將IPv6數據報文封裝在IPv4用戶數據報協定（UDP）數據包內。Teredo路由器將這些數據報在IPv4網際網路上傳輸及通過NAT設備。其他在IPv6網路上的Teredo節點（被稱為Teredo中繼，英文為Teredo relays）接收數據包，解開它們的封裝，以及傳遞它們。
Teredo是一種臨時措施。在長遠的未來，所有IPv6主機都應該使用本地的IPv6連線。Teredo應在原生IPv6連線可用時被停用。Christian Huitema在微軟開發了Teredo，並且網際網路工程任務組（IETF）將其標準化為RFC4380。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協定執行幾種功能：
診斷UDP通過IPv4（UDPv4）的連通性並發現當前的NAT種類（使用STUN協定的簡化版）
為每個使用它的主機分配一個全局可路由的唯一IPv6地址
將IPv6數據包封裝在UDPv4數據報中以通過IPv4網路傳輸（包括NAT穿透）
在Teredo主機與原生（或其他非Teredo）IPv6主機路由流量
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地址。
•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地址，將所有比特翻轉。
圖1 Teredo IPv6地址表舉例來說，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）
圖2 Teredo IPv6示例表伺服器
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。
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地址）的連線埠號相同。若無此假設，兩個客戶端直接不可能創建直接通信，從而中繼不得不進行三角形路由。一個Teredo實現嘗試在啟動時檢測NAT類型，並且如果NAT看起來對稱，則拒絕運作。（此限制有時可以在NAT設備上配置轉發規則來解決，但這需要NAT設備的管理許可權。）
Teredo只能為每個隧道端點提供一個IPv6地址。因此，不能使用一個Teredo隧道連線多個主機，這不同於6to4和某些點對點IPv6隧道。所有Teredo客戶端與IPv6網際網路的可用頻寬都受到Teredo中繼可用資源的限制，這與6to4等中繼沒什麼區別。
