Loading learning content...
Both configured tunnels and 6to4 share a critical limitation: they use Protocol 41 (IPv6 encapsulation) directly over IPv4. This works fine when tunnel endpoints have public IPv4 addresses, but what about the vast majority of Internet hosts that sit behind NAT?
NAT devices are designed to handle TCP and UDP—protocols with port numbers that enable connection tracking. When NAT sees Protocol 41, it has no port to map, no connection state to track. Most NAT devices simply drop it.
This meant that billions of hosts behind residential and corporate NAT couldn't use 6to4 or configured tunnels. They were locked out of IPv6 connectivity despite wanting it.
Teredo solved this by encapsulating IPv6 inside UDP—a transport protocol that NAT devices understand and can translate. Developed by Microsoft and standardized as RFC 4380, Teredo enabled IPv6 connectivity for hosts behind even the most restrictive NAT configurations.
By the end of this page, you will understand why NAT breaks Protocol 41 tunneling, how Teredo uses UDP encapsulation to traverse NAT, the roles of Teredo servers and relays, the unique address format that encodes NAT information, NAT traversal techniques (including hole punching), and why Teredo is now considered legacy technology.
To understand Teredo's value, we must first understand why NAT blocks simpler tunneling mechanisms.
Network Address Translation (NAT) allows multiple internal hosts to share a single public IPv4 address by translating addresses and port numbers:
The key insight: NAT relies on port numbers to demultiplex returning traffic among internal hosts.
When a host behind NAT tries to send a Protocol 41 packet:
IPv4 Header:
Source: 192.168.1.10
Destination: 192.88.99.1 (6to4 relay)
Protocol: 41 (IPv6)
[No port numbers!]
Payload:
Complete IPv6 packet
The NAT device faces a dilemma:
NAT device behavior varies:
Result: Protocol 41 tunneling is unreliable or impossible through most NAT devices.
NAT behavior is classified into types: Full Cone, Restricted Cone, Port Restricted Cone, and Symmetric. Even the most permissive 'Full Cone' NAT struggles with Protocol 41 because there are no ports. Teredo was designed to work with all NAT types, including the most restrictive Symmetric NAT.
Teredo encapsulates IPv6 packets inside UDP datagrams, using UDP's port numbers to survive NAT translation. The result: any host capable of outbound UDP can establish IPv6 connectivity, regardless of NAT.
+------------------------------------+
| IPv4 Header (20 bytes) |
| - Protocol: 17 (UDP) |
+------------------------------------+
| UDP Header (8 bytes) |
| - Source Port: mapped by NAT |
| - Destination Port: 3544 (Teredo) |
+------------------------------------+
| Teredo Header (optional) |
| - Origin indication, nonce, etc |
+------------------------------------+
| IPv6 Packet (40+ bytes) |
| - Complete IPv6 datagram |
+------------------------------------+
Port 3544 is the IANA-assigned port for Teredo. All Teredo infrastructure listens on this port, and NAT devices see it as ordinary UDP traffic.
A Teredo system involves four component types:
1. Teredo Client
2. Teredo Server
3. Teredo Relay
4. Teredo Host-Specific Relay
A critical distinction: Teredo servers only handle signaling (discovery, qualification). Data traffic never touches them. Teredo relays handle data forwarding between Teredo and native IPv6. This separation allows lightweight servers and heavy-duty relays optimized for different roles.
Teredo addresses encode remarkable information: the Teredo server used, NAT type flags, the client's external (post-NAT) port, and external IPv4 address—all within 128 bits.
| 32 bits | 32 bits | 16 bits | 16 bits | 32 bits |
+-------------+-----------+---------+-----------+-------------+
| Prefix | Server | Flags | Obfusc. | Obfusc. |
| 2001:0000 | IPv4 | | Port | IPv4 |
+-------------+-----------+---------+-----------+-------------+
Field Breakdown:
The port and IPv4 address are XOR'd with all-1s (obfuscated) to prevent broken NAT devices from 'helpfully' modifying them. Some NAT devices scan packet payloads for IP addresses and rewrite them—this breaks Teredo if the addresses in the Teredo header match the outer addresses. XOR obfuscation makes them unrecognizable.
Example Calculation:
Given:
Teredo Server: 65.54.227.120
External IPv4: 192.0.2.45
External Port: 40000
Step 1: Convert server to hex
65.54.227.120 → 4136:e378
Step 2: Obfuscate port
40000 = 0x9C40
0x9C40 XOR 0xFFFF = 0x63BF
Step 3: Obfuscate IPv4
192.0.2.45 = 0xC0000223
0xC0000223 XOR 0xFFFFFFFF = 0x3FFFFDDC
Step 4: Assemble address
2001:0000:4136:e378:8000:63bf:3fff:fddc
^^^^^^^^^ ^^^^^^ ^^^^^^^^^^^^
Server Flags Obfusc. Port+IP
IPv4 +Port
The Flags field's high bit (0x8000) indicates Cone NAT in this example.
| Bit | Name | Meaning |
|---|---|---|
| 15 (MSB) | Cone | 1 = NAT is Cone type (more permissive) |
| 14 | Reserved | Must be 0 |
| 13 | Random Port | 1 = NAT uses random port allocation |
| 12 | Random Address | 1 = NAT may change its address |
| 11-0 | Reserved | Must be 0 |
Given a Teredo address, you can determine the client's external IPv4 and port by de-obfuscating: XOR the last 32 bits with 0xFFFFFFFF for the IPv4, and XOR bits 65-80 with 0xFFFF for the port. This is how relays know where to send UDP packets.
Before a Teredo client can establish its IPv6 address, it must determine its NAT type and external address/port. This qualification process uses the Teredo server.
Step 1: Router Solicitation The client sends an ICMPv6 Router Solicitation inside a Teredo packet to the Teredo server (UDP port 3544).
Step 2: Server Response The server observes the source IPv4 address and UDP port that arrived (the NAT's external address/port) and responds with a Router Advertisement containing:
Step 3: NAT Type Determination To determine NAT type, the client sends to a secondary server IP or port. If responses arrive from different ports/addresses, the client can determine:
Cone NAT (also called 'Endpoint-Independent Mapping'):
Symmetric NAT (Endpoint-Dependent Mapping):
Why This Matters: With Cone NAT, two Teredo clients can communicate directly (hole punching). With Symmetric NAT, the port changes per destination, so direct communication fails—traffic must always route through relays.
Modern Reality: Most consumer NAT devices are Restricted Cone or Port Restricted Cone (allowing Teredo to work reasonably well). Symmetric NAT is more common in enterprise/carrier-grade environments.
NAT mappings expire after inactivity (typically 30-120 seconds for UDP). Teredo clients must send periodic 'keepalive' messages to maintain their NAT mapping and external address. If keepalives fail, the client loses its Teredo address and must re-qualify.
Teredo supports several communication patterns, each optimized for different scenarios.
When a Teredo client connects to a native IPv6 host:
Note: Inbound and outbound may use different relays (similar to 6to4's asymmetry concern).
When both clients have Cone NAT, direct tunneling is possible:
Problem: Client B's NAT might not have an open mapping for Client A.
Solution: Hole Punching
The server facilitates hole punching by relaying the initial request to establish NAT mappings on both sides.
| Scenario | Path | Efficiency |
|---|---|---|
| Teredo ↔ Native IPv6 | Via Relay | One hop through relay |
| Teredo ↔ Teredo (Cone NAT) | Direct (after hole punch) | Optimal—no relay needed |
| Teredo ↔ Teredo (Symmetric NAT) | Via Relay | Both clients use relay |
| Teredo ↔ 6to4 | Native relay (2002::/16) | Complex; avoid if possible |
Hole punching is elegant: by having both parties simultaneously create outbound NAT mappings to each other, inbound traffic becomes possible. This technique is used far beyond Teredo—VoIP, gaming, and WebRTC all use hole punching variants. Teredo was an early widespread application of the concept.
Teredo was developed by Christian Huitema at Microsoft, and Windows has been the primary Teredo platform. Understanding Windows' implementation is key to understanding Teredo's real-world behavior.
Windows Teredo creates a virtual network adapter (Teredo Tunneling Pseudo-Interface) that:
Microsoft operated public Teredo servers for Windows users:
teredo.ipv6.microsoft.com (historic)
win1710.ipv6.microsoft.com (current)
win10.ipv6.microsoft.com (alternative)
These are true servers (not relays)—they only handle qualification, not data forwarding.
# View Teredo status
netsh interface teredo show state
# Enable Teredo
netsh interface teredo set state type=default
# Disable Teredo
netsh interface teredo set state type=disabled
# Set custom server
netsh interface teredo set state servername=custom.server.com
Example Output:
Teredo Parameters
---------------------------------------------
Type : default
Server Name : win1710.ipv6.microsoft.com
Client Refresh Interval : 30 seconds
Client Port : unspecified
State : qualified
Client Type : teredo client
Network : unmanaged
NAT : restricted
Local Mapping : 192.168.1.10:52394
External NAT Mapping : 203.0.113.45:40234
Many enterprises disable Teredo via Group Policy because it creates uncontrolled IPv6 connectivity. A host with Teredo might be reachable via IPv6 from the Internet, bypassing enterprise perimeter security. Security-conscious environments should explicitly disable Teredo unless specifically needed.
Teredo's ability to traverse NAT—often considered a security boundary—raises significant security concerns.
While NAT is not a firewall, it provides implicit protection: hosts behind NAT are unreachable from the Internet unless they initiate outbound connections. Teredo circumvents this:
Result: Teredo converts hosts from 'unreachable behind NAT' to 'globally reachable.' This is a fundamental change in security posture.
RFC 4380 and subsequent updates addressed some concerns:
Origin Indication: Teredo packets include 'origin indication' headers that encode the sender's mapped address. This helps relays validate traffic source.
Nonce for Qualification: Randomized nonces during qualification prevent attackers from predicting external addresses.
Local Firewall Integration: Windows Firewall understands Teredo and applies rules to the Teredo interface. IPv6 firewall rules protect the Teredo address.
However: Many organizations still view Teredo as too risky. The safest approach in security-sensitive environments is to disable Teredo entirely and deploy native IPv6 under organizational control.
A determined user or malware can use Teredo to establish outbound connectivity through even restrictive firewalls—as long as outbound UDP to port 3544 is allowed. This is why security best practices include blocking UDP 3544 outbound if Teredo is not authorized.
Like 6to4, Teredo's relevance has diminished as native IPv6 deployment has accelerated. However, Teredo's decline has been more gradual.
1. Functional Infrastructure: Microsoft operated reliable Teredo servers, unlike 6to4's volunteer relays. This provided consistent user experience.
2. NAT Traversal Remained Necessary: Until ISPs widely deployed IPv6, NAT traversal was the only option for many users. Teredo filled this gap.
3. Tighter OS Integration: Windows' Teredo implementation was well-tested and maintained, unlike often-broken 6to4 host implementations.
| Feature | Teredo | Native IPv6 | NAT64/DNS64 |
|---|---|---|---|
| Configuration | Automatic | ISP-provided | ISP-configured |
| NAT traversal | Solved via UDP | N/A (no NAT) | Translation |
| Performance | Overhead + relay delay | Optimal | Translation overhead |
| Security control | Limited | Full | Controlled by ISP |
| Dependency | Microsoft servers | ISP | ISP |
| IPv4 access | Via dual-stack | Via dual-stack | Via NAT64 |
While Teredo itself is fading, its innovations influenced other protocols:
Hole Punching: Teredo helped popularize NAT traversal techniques that are now fundamental to:
UDP Encapsulation: The pattern of encapsulating arbitrary protocols in UDP (to traverse NAT) is now common:
Teredo proved that UDP encapsulation could enable complex protocol traversal through uncooperative middleboxes.
The declining need for Teredo is a positive indicator: it means native IPv6 is becoming the default. The goal of all transition mechanisms—including Teredo—was always to become unnecessary. In that sense, Teredo's obsolescence represents success.
Teredo solved a critical problem—IPv6 connectivity through NAT—with an ingenious UDP-based approach. Let's consolidate the key principles:
What's Next:
The final mechanism in this module is NAT64—a fundamentally different approach. Rather than encapsulating IPv6 in IPv4, NAT64 translates between the protocols. This enables IPv6-only networks to access IPv4-only Internet services, which is essential as some networks move to IPv6-only operation while legacy IPv4 content remains.
You now understand Teredo comprehensively: why NAT breaks Protocol 41 tunneling, how UDP encapsulation solves this, the server/relay architecture, address format with obfuscation, NAT qualification and hole punching, Microsoft's implementation, security concerns, and Teredo's legacy. This knowledge helps you understand both legacy Teredo deployments and the evolution of NAT traversal techniques.