Does a Teredo server carry all application data like a relay?

A Teredo server helps clients establish their address and connectivity through control exchanges; its server role does not forward ordinary application data. A relay forwards ordinary traffic between Teredo and native IPv6 nodes. One device can perform both roles, so the functional distinction does not require two separate physical machines.

Is every Teredo packet sent to UDP port 3544?

Teredo servers use UDP port 3544, but client and peer mappings can use other ports. The Windows client uses a dynamic service port that can change when the client restarts. Filtering only destination port 3544 therefore does not cover all Teredo traffic.

Which reverse DNS namespace applies to a tunnel's IPv6 address?

Reverse DNS (Domain Name System) lookups for an IPv6 address use ip6.arpa. Embedded IPv4 fields do not change that namespace; a reverse lookup for the extracted IPv4 address is a separate lookup.

What link MTU does the basic Teredo design recommend?

The recommended IPv6 link MTU for the basic Teredo design is 1280 bytes. This limit applies to the inner IPv6 packet, not the enclosing IPv4 packet; check the tunnel interface to find its configured MTU.

Why can a Teredo flags field contain values other than 0000 or 8000?

Teredo's updated flags format uses 12 formerly unused bits for random values. Clients and relays are advised to ignore the cone flag, which previously indicated a NAT that accepted traffic from any external host at its mapped address and port. Older interpretations that expect only 0000 or 8000, or infer NAT behavior directly from that flag, are incomplete.

How does ISATAP differ from 6to4 and Teredo?

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) carries IPv6 across an IPv4 infrastructure within a site. An ISATAP address includes a 5efe field and an IPv4 address in the interface identifier, rather than using the 6to4 or Teredo service prefix to identify the mechanism.

Does 6rd use the 2002 prefix?

IPv6 rapid deployment (6rd) uses a service provider's IPv6 prefix, rather than requiring the fixed 2002::/16 prefix. Provider domain parameters then determine how customer prefixes are constructed.

Can two 6to4 sites communicate without a native IPv6 relay?

Two 6to4 sites can exchange IPv6 traffic directly through their IPv4 endpoints, without a native IPv6 relay, when protocol-41 traffic is permitted between those endpoints.

Does a working website prove that a legacy IPv6 path is healthy?

A working website does not prove that IPv6 succeeded, because an application supporting both IPv4 and IPv6 can complete the connection over IPv4 when IPv6 fails. Happy Eyeballs reduces delays by trying multiple addresses, so check which address family carried the connection before relying on the page load to confirm IPv6 connectivity.

Does default address selection always favor these tunnels over IPv4?

The default policy table assigns higher precedence to IPv4-mapped addresses, which represent IPv4 destinations, than to 6to4 or Teredo addresses. The values are 35, 30, and 5 respectively; other selection rules, configured policy, and application behavior can change which address is attempted first.

Legacy IPv6 Tunnels: 6to4 and Teredo

6to4 and Teredo are IPv6 transition mechanisms that carry IPv6 traffic across IPv4 networks. A 6to4 address belongs to 2002::/16, while a Teredo address belongs to 2001:0000::/32. Those prefixes help identify legacy tunnel configuration in an address list or network inventory.

An address or adapter entry alone does not establish that the tunnel works. It also does not demonstrate native IPv6 service on the underlying network. Each mechanism needs its own supported endpoints, routing, and packet handling.

Recognize the Address Structure

The two mechanisms encode different information in their IPv6 addresses. Read the prefix length together with the address, particularly when compressed notation hides zero-valued groups.

6to4 Starts with 2002

The first 16 bits identify 6to4. The next 32 bits encode an IPv4 address, producing a /48 site prefix. A further 16-bit subnet field and a 64-bit interface identifier complete the IPv6 address.

Consider the illustrative address 2002:c000:023d:5::20. Split the encoded IPv4 portion c000:023d into four hexadecimal bytes: c0, 00, 02, and 3d. Their decimal values are 192, 0, 2, and 61, giving 192.0.2.61. The resulting site prefix is 2002:c000:023d::/48, with subnet 5 in this example.

The embedded IPv4 address represents the 6to4 site's IPv4 endpoint. It is not necessarily an IPv4 address assigned to the individual IPv6 host behind that endpoint. Reading the field therefore does not identify a particular computer or account.

This example embeds an IPv4 documentation address to show the format. It is not a usable Internet tunnel configuration: actual basic 6to4 operation requires a suitable globally reachable IPv4 address.

Teredo Starts with 2001:0000

The Teredo prefix occupies 32 bits, so its first two fully expanded groups are 2001:0000. An address beginning with 2001 alone is insufficient evidence. For example, the documentation prefix 2001:db8::/32 is outside the Teredo allocation.

After the prefix, a Teredo address contains a 32-bit server IPv4 address, 16 bits of flags, a 16-bit obfuscated User Datagram Protocol (UDP) port, and a 32-bit obfuscated client IPv4 address. The decoded client fields identify the externally visible IPv4 address and UDP port. If a network address translation (NAT) device is present, it translates IPv4 addresses and may also translate ports.

For a hypothetical decoding exercise, use 2001:0000:c000:023d:00a2:efff:39cc:9bd2. Its fields yield:

Server address: c000:023d decodes to 192.0.2.61.
Flags: 00a2 is the flags field.
Mapped UDP port: complementing the 16 bits of efff gives 1000 hexadecimal, or 4096 decimal.
Mapped client address: complementing the 32 bits of 39cc:9bd2 gives c633:642d, which decodes to 198.51.100.45.

Here, complementing means flipping every bit within the specified field. It is a reversible encoding operation, with no secret key. Both decoded IPv4 addresses are documentation examples, so the result illustrates the structure without representing a working Teredo client or server.

Inspect an Adapter's Actual State

A tunnel interface may appear separately from an Ethernet or Wi-Fi interface. Names and presentation vary by operating system and version. Match an entry's addresses and mechanism-specific state instead of treating a familiar adapter name as proof of a functioning connection.

On Windows 11 or Windows Server 2025, these commands display IPv6 addresses and the respective tunnel states:

netsh interface ipv6 show addresses
netsh interface 6to4 show state
netsh interface teredo show state

The first command lists IPv6 addresses; the other two show the configuration and status of 6to4 and Teredo. These commands inspect the current settings without changing them.

An interface can exist without a usable route to the destination. A disabled tunnel or an unsupported tunnel command also says nothing by itself about whether native IPv6 works on the device.

Why These Mechanisms Were Deployed

Basic 6to4 connected IPv6 sites over IPv4 using addresses derived from their IPv4 endpoints. IPv6 traffic crosses the IPv4 portion through IP protocol 41 encapsulation. This number identifies an IP payload type; it is not a Transmission Control Protocol (TCP) or UDP port.

Teredo addressed a different obstacle: IPv6 communication by hosts behind IPv4 NAT. It carries IPv6 inside UDP over IPv4, allowing a suitable NAT mapping to transport the encapsulated traffic. The network still needs to permit that communication, and the implementation must support the relevant NAT behavior.

Neither mechanism adds IPv6 support to an IPv4-only application. Each provides a way to carry IPv6 traffic where the intervening network is IPv4. Application support, destination reachability, and the mechanism's operational requirements remain separate considerations.

Legacy Paths Have Several Points of Failure

For 6to4 communication with native IPv6 destinations, relays forward traffic between the tunnel and the native IPv6 network. Traffic going out and coming back may use different relays. A reachable outward relay therefore provides only part of the required path.

Protocol 41 filtering can interrupt a 6to4 path while ordinary IPv4 traffic continues to pass. A route to a relay can also exist without a relay successfully forwarding the encapsulated packet. Checking only the local address or route entry misses those possibilities.

Private IPv4 addressing creates another limitation for basic 6to4. An endpoint cannot turn an ordinary private address behind NAT into a valid public 6to4 endpoint merely by embedding that address after 2002.

Teredo's UDP encapsulation has its own dependencies. NAT mappings, filtering behavior, and local tunnel policy affect whether traffic reaches the peer. An available adapter does not guarantee that every NAT arrangement or remote peer is compatible. When a connection fails, check the NAT, filtering, and tunnel settings before enabling another tunnel mechanism.

How Encapsulation Increases Packet Size

Assume a complete inner IPv6 packet of 1200 bytes, an outer IPv4 header of 20 bytes with no options, and no additional mechanism headers. Basic 6to4 produces a 1220-byte IPv4 packet. With the same inner packet and IPv4 header, Teredo adds an eight-byte UDP header, producing a 1228-byte enclosing packet.

Additional headers can make the enclosing packet larger than these examples. The extra headers reduce the space available for an IPv6 packet to cross the IPv4 path without fragmentation. A tunnel's maximum transmission unit (MTU) limits the size of the IPv6 packet it accepts. An oversized enclosing IPv4 packet may need fragmentation or trigger a packet-size error, so a successful small exchange does not prove that larger packets will pass.

Anycast 6to4 Relay Deprecation

The deprecated anycast 6to4 relay mechanism used the shared IPv4 address 192.88.99.1 to reach a relay. Both this relay mechanism and the associated 6to4 Provider Managed Tunnels design are deprecated. The anycast relay should not be offered as a general fallback for obtaining IPv6 connectivity.

Basic unicast 6to4 and the 2002::/16 IPv6 prefix are outside this deprecation. This distinction explains why the prefix can still appear in registries or existing configuration. It does not establish that a specific deployment has working relays or current support.

Teredo is a separate protocol. This 6to4 anycast deprecation does not deprecate Teredo as a whole. A Teredo implementation's support and suitability need to be assessed for its own platform and intended application.

Apply Policy to the Carried IPv6 Traffic

A security device that inspects only an outer IPv4 or UDP header can miss the IPv6 packet inside. Tunnel-aware processing or inspection after decapsulation determines whether the intended IPv6 traffic controls are applied.

Encapsulation and reversible address encoding do not provide encryption. A host behind NAT also needs appropriate policy for IPv6 traffic admitted through a tunnel. The traffic policy needs to cover the IPv6 packet exposed at decapsulation as well as the outer transport.

Use Supported IPv6 Connectivity

Prefer IPv6 service supplied and supported by the network provider or administrator. Where native service is available, identify its assigned addresses and route separately from legacy tunnel entries. A tunnel can also be appropriate when an operator explicitly supports its endpoints, routing, and packet handling for a defined purpose.

If a particular application requires Teredo, use that application's supported platform guidance and the network administrator's policy to assess it. An unexplained adapter name is insufficient reason to install an old driver, substitute a historical public relay, or change global IPv6 settings.

Before changing a tunnel configuration, check whether the tunnel serves only that device or acts as a gateway for other hosts. Changing a gateway's tunnel can affect an entire site's IPv6 addresses and routes.