Teredo: IPv6 Through NAT via UDP Encapsulation

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.

To understand Teredo's value, we must first understand why NAT blocks simpler tunneling mechanisms.

How NAT Works (Review)

Network Address Translation (NAT) allows multiple internal hosts to share a single public IPv4 address by translating addresses and port numbers:

1. Outbound packet from internal host (192.168.1.10:5000) to external server
2. NAT rewrites source to public address (203.0.113.1:40000)
3. NAT creates mapping: 192.168.1.10:5000 ↔ 203.0.113.1:40000
4. Response arrives for 203.0.113.1:40000
5. NAT uses mapping to forward to 192.168.1.10:5000

The key insight: NAT relies on port numbers to demultiplex returning traffic among internal hosts.

Protocol 41: No Ports to Map

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:

• It can translate 192.168.1.10 → 203.0.113.1
• But what about return traffic? Multiple internal hosts might send Protocol 41
• Without port numbers, it can't distinguish which internal host should receive replies

NAT device behavior varies:

• Drop the packet: Most common; NAT doesn't understand Protocol 41
• Allow first only: Some NAT devices allow one Protocol 41 'connection' at a time
• Random forwarding: Some (incorrectly) forward to last internal host that sent

Result: Protocol 41 tunneling is unreliable or impossible through most NAT devices.

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.

The Teredo Encapsulation

+------------------------------------+
|      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.

Teredo Components

A Teredo system involves four component types:

1. Teredo Client

• Host behind NAT seeking IPv6 connectivity
• Initiates communication with Teredo server
• Maintains NAT keepalive traffic
• Has a Teredo IPv6 address (2001:0::/32 prefix)

2. Teredo Server

• Helps clients determine their NAT type and external address
• Provides the client's Teredo IPv6 address
• Facilitates initial connection establishment
• Does not forward data traffic (only signaling)

3. Teredo Relay

• Gateway between Teredo and native IPv6
• Forwards traffic between Teredo clients and native IPv6 hosts
• Announces 2001:0::/32 into native IPv6 routing

4. Teredo Host-Specific Relay

• A dual-stack host that can communicate directly with Teredo clients
• Acts as both endpoint and relay for its own traffic

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.

Address Structure

|   32 bits   |  32 bits  | 16 bits |  16 bits  |   32 bits   |
+-------------+-----------+---------+-----------+-------------+
|   Prefix    |  Server   |  Flags  |  Obfusc.  |  Obfusc.   |
|  2001:0000  |   IPv4    |         |   Port    |   IPv4     |
+-------------+-----------+---------+-----------+-------------+

Field Breakdown:

• Prefix (32 bits): 2001:0000::/32 — Identifies Teredo addresses globally
• Server IPv4 (32 bits): IPv4 address of the Teredo server that assigned this address
• Flags (16 bits): NAT type indicators (Cone, Random Port, etc.)
• Obfuscated Port (16 bits): External UDP port XOR'd with 0xFFFF
• Obfuscated IPv4 (32 bits): External IPv4 address XOR'd with 0xFFFFFFFF

Why Obfuscation?

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.

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.

The Qualification Procedure

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:

• The client's observed external IPv4 address
• The client's observed external UDP port
• The Teredo prefix for address construction

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: Responds to packets from any source
• Restricted NAT: Only responds to sources it has sent to
• Symmetric NAT: Changes port mapping per destination

Cone vs Symmetric NAT Impact

Cone NAT (also called 'Endpoint-Independent Mapping'):

• Same internal endpoint always maps to same external endpoint
• Any external host can send to the mapped port
• Teredo works efficiently with direct communication

Symmetric NAT (Endpoint-Dependent Mapping):

• Different external port for each destination
• Only the specific destination can respond
• Teredo must use relay for all traffic (can't do direct)

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.

Teredo supports several communication patterns, each optimized for different scenarios.

Pattern 1: Teredo Client to Native IPv6

When a Teredo client connects to a native IPv6 host:

1. Client sends IPv6 packet to native destination (e.g., 2001:db8::1)
2. Packet is encapsulated in UDP and sent to Teredo relay
3. Relay decapsulates and forwards natively to 2001:db8::1
4. Native host responds to the Teredo address (2001:0:...)
5. Response routes through native IPv6 to a Teredo relay (announcing 2001:0::/32)
6. Relay encapsulates in UDP and sends to client's external address:port
7. Client's NAT forwards to internal client

Note: Inbound and outbound may use different relays (similar to 6to4's asymmetry concern).

Pattern 2: Teredo Client to Teredo Client (Same NAT Type)

When both clients have Cone NAT, direct tunneling is possible:

1. Client A looks at Client B's Teredo address
2. Extracts Client B's external IPv4 and port (de-obfuscates)
3. Sends UDP directly to Client B's external address:port
4. Client B's NAT forwards to Client B (if mapping exists)

Problem: Client B's NAT might not have an open mapping for Client A.

Solution: Hole Punching

1. Client A sends 'bubble' packet to Client B's external address
2. Client A's NAT creates mapping for Client B's address
3. Meanwhile, Client B sends 'bubble' to Client A's external address
4. Client B's NAT creates mapping for Client A's address
5. Both NATs now have mappings; direct traffic flows

The server facilitates hole punching by relaying the initial request to establish NAT mappings on both sides.

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 History

• Windows XP SP2 (2004): Teredo introduced, disabled by default
• Windows Vista (2006): Teredo enabled by default
• Windows 7-10: Teredo present but increasingly deprecated
• Windows 11: Teredo available but not favored; native IPv6 preferred

Windows Teredo Architecture

Windows Teredo creates a virtual network adapter (Teredo Tunneling Pseudo-Interface) that:

• Has a Teredo IPv6 address
• Routes 2001:0::/32 traffic
• Falls back to other transition technologies (6to4) if Teredo fails
• Maintains keepalives automatically

Microsoft Teredo Servers

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.

Windows Teredo Commands

# 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

Teredo's ability to traverse NAT—often considered a security boundary—raises significant security concerns.

NAT as 'Security'

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:

• A Teredo-enabled host has a globally routable IPv6 address
• Any IPv6 host on the Internet can initiate connections to it
• The NAT device doesn't block incoming traffic (it's encapsulated in UDP from the relay)

Result: Teredo converts hosts from 'unreachable behind NAT' to 'globally reachable.' This is a fundamental change in security posture.

Teredo Security Enhancements

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.