Teredo: the IPv6-over-UDP tunneling that IPv4 NAT ate in 2026

Teredo was supposed to be the way to give every IPv4-only user behind a NAT box a globally routable IPv6 address. In 2026 it’s basically a museum piece — Microsoft ships it disabled by default, public Teredo servers have all but disappeared, and Linux support is gone. This article explains what Teredo was, how it actually worked, and what replaced it.

Teredo is the protocol defined in RFC 4380 (February 2006, C. Huitema of Microsoft, Proposed Standard). It was designed to solve one specific problem: a host behind one or more layers of IPv4 NAT, with no cooperation from the local network operator, needs a globally routable IPv6 address and a path to the IPv6 Internet.

By 2026 the problem is mostly gone — most ISPs and content providers are dual-stack — but the protocol and the security lessons are still worth knowing.

The problem Teredo solved (and why it no longer matters)

The early-to-mid 2000s: a significant fraction of the world’s Internet users were behind NAT boxes (most consumer routers), and a growing fraction of the world’s content was IPv6-only or preferred IPv6. A user with an IPv4-only ISP and a SOHO NAT couldn’t get IPv6 without changing the ISP — which usually wasn’t an option. The IETF spent 2002-2005 designing Teredo specifically as a last-resort tunnel that would work through a NAT, without the user doing anything more than running a client.

By 2026:

• Google IPv6 stats regularly exceed 40-50% of users globally (measured at Google)
• Most major content providers (Google, Meta, Cloudflare, Akamai-fronted properties) are dual-stack or IPv6-preferred
• Most transit networks and IXPs have native IPv6
• “IPv4-only ISP” is now the minority, not the majority
• The use case Teredo was designed to address has shrunk to “old equipment in a few regions”

That’s why Teredo fell out of favor. The 2019-12-30 MaxMind GeoLite2 license change and the 2021 Miredo sunset and the 2024 Linux kernel removals are all downstream consequences of the same fact: the problem Teredo solved is no longer common enough to justify keeping the code alive.

How the protocol actually worked

Teredo is IPv6-in-IPv4-in-UDP. The outer UDP port is 3544 (RFC 4380 §2.7). The Teredo IPv6 prefix is 2001:0000::/32 — the address a Teredo client is assigned looks like 2001:0:xx:yy:zzzz:aaaa:bbbb:cccc where the embedded IPv4 and NAT cone bits let the relay de-NAT the packet.

The architecture has three components:

1. Teredo client — a host behind one or more NATs that wants IPv6. Maintains a tunnel, encapsulates outbound IPv6 packets in IPv4/UDP/3544.
2. Teredo server — a stateless IPv4 rendezvous point. It assigns the client a Teredo IPv6 address (the address encodes the client’s public IPv4 + the cone NAT flag), and it relays the initial bubble exchange so the NAT mapping on the client’s path is created.
3. Teredo relay — an IPv6 router that decapsulates UDP/3544 from clients and forwards the resulting IPv6 packets to the native IPv6 Internet, and vice versa.

The “bubble” is a small ICMPv6 echo packet (Router Solicitation + Router Advertisement + an extra “bubble” ICMPv6 echo) that the server reflects back to the client. The whole point of the bubble is to punch a hole in the NAT mapping — most NAT boxes create a temporary outbound mapping when they see an outbound UDP packet, and the bubble does just that, but coming from the server, not from a peer. Once the NAT mapping exists, subsequent packets from a peer flow peer-to-peer through the relay, bypassing the server.

This works for “cone NATs” — NATs where the same external port maps to the same internal host for any peer. It does not work for symmetric NATs (where the mapping depends on the destination). For symmetric NATs, the Teredo client falls back to a “Teredo relay” mode where all traffic flows through a relay — which is why Teredo has always been a worst-case fallback, not a primary connectivity mechanism.

RFC 4380 metadata

Security concerns (these are why nobody trusts Teredo on a production network)

• The Teredo relay sees all client traffic in clear. There’s no end-to-end confidentiality between two Teredo clients; the relay can read every packet. For most “I just want IPv6” use cases this is fine, but for anything that touches credentials or PII, this is a deal-breaker.
• Open Teredo relays are routinely abused for IPv6→IPv4 SSRF and DDoS reflection. The relay will forward any encapsulated IPv6 packet to any IPv4 destination, so a misconfigured relay becomes a free packet-laundering service for attackers.
• Symmetric NATs defeat the bubble exchange. Users on such NATs fall back to the relay, which compounds the abuse vector.
• Errata 107 on RFC 4380 itself notes the original spec was inconsistent on MAC algorithm (MD5 vs SHA-1).

Status in 2026

Windows 10 / 11

Still ships in Windows. Auto-goes “dormant” when native IPv6 is available. Microsoft has been progressively disabling it in default consumer SKUs since the Windows 10 21H1 era. You can re-enable it via:

# Check current state
Get-NetTeredoConfiguration
# Enable
Set-NetTeredoConfiguration -Type Enterpriseclient
netsh interface teredo set state enterpriseclient
# Or via Group Policy
Computer Configuration → Administrative Templates → Network → TCPIP Settings → IPv6 Transition Technologies

Microsoft itself recommends native IPv6 or 6to4-disabled-only configurations. The remaining users of Teredo on Windows are mostly legacy DirectX / Xbox Live peer-to-peer applications that predate the native IPv6 era.

Linux kernel

The Linux kernel in-kernel Teredo client support (the experimental CONFIG_NET_TUN with Teredo encapsulation) was historically behind Miredo — the primary userland implementation. Miredo’s author sunset the project in June 2021 (announced on remlab.net/miredo). The CZ.NIC (Czech Republic NIC) public Teredo server was shut down in October-November 2021 (announced at en.blog.nic.cz/2021/10/25). Hurricane Electric was documented in 2021 as “one of the last” public Teredo operators; its current (2026) status as a public anycast Teredo relay under 2001::/32 is not publicly documented.

The practical answer for “I want IPv6 on Linux in 2026” is not Teredo.

macOS, iOS, Android

Never had native Teredo client support. Apple’s IPv6 transition story is 464XLAT (used on iOS / cellular carriers). Android is the same. The Teredo client only ever shipped on Windows, BSD, and (in userland) Linux via Miredo.

Public Teredo servers

Effectively zero in 2026. Miredo’s author shut down his public server in 2021 without notice. CZ.NIC followed. Hurricane Electric’s status is unverified, but their primary public service is tunnelbroker.net for 6in4 (a much simpler protocol) rather than Teredo.

What replaced Teredo in 2026

The dominant modern pattern is “be dual-stack by default, fall back to CGNAT+464XLAT on cellular, use DS-Lite or MAP-E where the ISP doesn’t have native IPv6 yet.” Teredo is a historical curiosity at this point.

Practical advice for 2026

If you actually want IPv6 in 2026:

1. Use Hurricane Electric’s tunnelbroker.net. Free, 6in4, requires a public IPv4 endpoint you control. Get a /48 or /64, configure the routed prefix, done.
2. Use Cloudflare WARP. Free, encrypted, dual-stack, runs on most devices, no server to manage.
3. Use a WireGuard tunnel to a VPS that has native IPv6. Most cheap VPS providers (Vultr, DigitalOcean, Linode, BandwagonHost) have native IPv6 by default.
4. If you are behind CGNAT with no public IPv4, request DS-Lite or 464XLAT from your ISP. If they don’t offer it, use WARP.
5. Don’t run Teredo. There are essentially no public Teredo servers left, no in-kernel Linux client, and the security story is bad.

If you need to research Teredo (for a paper, a class, or because you maintain a legacy app that uses it), read RFC 4380 and run the historical Miredo (still in some distro archives) against a private lab Teredo server you stand up yourself. Capture the bubble exchange with Wireshark on UDP/3544. It’s a 30-minute lab and you learn more than any article can teach.

TL;DR

Teredo was a 2006-vintage tunnel-over-UDP/3544 protocol for giving IPv4-NAT’d hosts a globally-routable IPv6 address. It worked via a three-way “bubble” exchange that punched a NAT mapping, then peer-to-peer traffic flowed. By 2026 the problem it solved (IPv4-only ISPs, IPv6-only content) is mostly gone — most networks are dual-stack, most ISPs offer some form of native IPv6, and 464XLAT/DS-Lite/WireGuard/WARP all cover the remaining CGNAT cases better. The Linux userland client (Miredo) was sunset in 2021. The Linux kernel in-kernel native Teredo client has been progressively stripped across recent LTS releases. Public Teredo servers are effectively all gone. Microsoft still ships the client in Windows for legacy DirectX / Xbox Live compatibility, but disabled by default. The lessons from Teredo — about bubble punching, about how NAT transparency can be purchased with UDP encapsulation, about how a 2006 tunnel protocol looks quaint by 2026 — are still worth knowing, but the protocol itself is not a 2026 answer to anything.

Sources verified July 2026: rfc-editor.org/info/rfc4380 (RFC 4380 metadata, Feb 2006, Proposed Standard, by C. Huitema); dl.acm.org/doi/book/10.17487/RFC4380 (DOI); rfc-editor.org/errata_search.php?rfc=4380 (errata 107); remlab.net/miredo/ (Miredo sunset June 2021, public servers shut down without notice); en.blog.nic.cz/2021/10/25/on-october-25-we-will-try-to-turn-off-ipv6-transition-technologies-teredo-and-6to4/ (CZ.NIC shutdown Nov 2021); kernelnewbies.org/Linux_6.12 (kernel 6.12 release date 17 Nov 2024); modern alternatives RFC 6877 (464XLAT), RFC 6333 (DS-Lite), RFC 7597 (MAP-E), RFC 5969 (6rd).