skip to content

How do the IPv6-over-IPv4 tunnels 6in4, 6to4, Teredo and ISATAP differ in finding the far end and crossing IPv4 networks?

level: middleimportance: should knowfreq 24%

answer

  1. configured versus automatic endpoints
  2. address embeds the IPv4 endpoint
  3. protocol 41 versus UDP
  4. site, internet, or behind NAT

basics

~20 s

6in4 is a manually configured tunnel over IP protocol 41; 6to4 derives the tunnel endpoint from a 2002::/16 address and needs relays; Teredo puts IPv6 in UDP to cross NAT; ISATAP tunnels inside one site.

solid answer

~40 s

All four wrap IPv6 in IPv4; they differ in how the far endpoint is found and what they can cross. **6in4** (a configured tunnel, RFC 4213) uses IP protocol 41 between two manually set endpoints — predictable, but it needs a path that passes protocol 41. **6to4** (RFC 3056) is automatic: a site with a public IPv4 address gets `2002:V4ADDR::/48`, so the endpoint is read from the destination address, and relays join it to native IPv6; RFC 7526 deprecated the anycast relay address, not 6to4 itself. **Teredo** (RFC 4380) carries IPv6 in UDP, server port 3544, so it crosses NATs — a last resort. **ISATAP** (RFC 5214) embeds the IPv4 address in the interface identifier and treats one site's IPv4 network as a link.

go deeper

for a junior

Recall the four names and one line each: configured protocol-41 tunnel, automatic 2002::/16 tunnel, IPv6 in UDP through NAT, intra-site tunnel.

for a middle

Explain how each finds its far end — configuration, the embedded IPv4 address, server qualification, a router list — and which kinds of IPv4 path each can cross.

for a senior

Explain why the automatic tunnels failed in practice — asymmetric third-party relays, symmetric NATs, address-selection rules ranking them below IPv4 — and when a configured tunnel is still the right tool.

for a principal

Judge whether any tunnel belongs in a transition plan today, against native IPv6 or translation, and what it would take to retire tunnels hosts enable on their own.

## What every IPv6-over-IPv4 tunnel does A tunnel joins IPv6 nodes across a network that only carries IPv4. The **encapsulator** puts an IPv4 header in front of the IPv6 packet; the **decapsulator** checks it, strips it and forwards the inner packet unchanged. RFC 4213 models the tunnel as a **single hop** for IPv6 and recommends a static tunnel MTU of **1,280 bytes** (1,280 to 1,480 allowed), since the outer IPv4 header takes at least 20 bytes. The four classic mechanisms differ in two questions: **how does the encapsulator learn the far end's IPv4 address**, and **what kind of IPv4 path can the tunnel cross**? ## 6in4 — the configured tunnel What people call **6in4** is the **configured tunnel** of RFC 4213 (Standards Track). Both endpoints' IPv4 addresses are set by an operator; the outer IPv4 header's Protocol field is **41**. The decapsulator MUST check that the outer source is the configured peer, which limits spoofing. - Predictable and easy to troubleshoot; a common way for a site without native IPv6 to reach a provider's IPv6 network. - Needs a path that delivers protocol 41 end to end. Protocol 41 carries no transport ports for a port-translating NAT to key a mapping on, so a host behind one generally cannot terminate the tunnel. ## 6to4 — the address is the tunnel endpoint **6to4** (RFC 3056) is **automatic**. A site whose border router has a globally unique IPv4 address gets the prefix `2002:V4ADDR::/48`; for `192.0.2.33` (a documentation address) that is `2002:c000:221::/48`. To reach another 6to4 site the router reads the destination's embedded IPv4 address and sends a protocol-41 packet straight to it — no configuration per peer. - Reaching **native** IPv6 needs **relay routers**: forward through one relay, and the return traffic comes back through whichever relay advertises `2002::/16` near the sender — usually a different one, operated by someone else. - An extension let hosts reach "the nearest relay" through the anycast address `192.88.99.1`. Because of high failure rates, **RFC 7526** (2015, Best Current Practice) deprecated that anycast mechanism and its prefix `192.88.99.0/24`. It states that unicast 6to4 and `2002::/16` themselves are **not** deprecated. - A host behind an IPv4 NAT cannot use its private address as V4ADDR; the 6to4 router must own the public address (RFC 3056 lets the NAT box itself be that router). ## Teredo — IPv6 in UDP, through NAT **Teredo** (RFC 4380) exists for hosts behind IPv4 NAT, on the observation that TCP and UDP are the only protocols guaranteed to cross most NATs. It puts IPv6 inside **UDP**. - A client **qualifies** with a Teredo server at **UDP port 3544**, which tells it its NAT's external mapping. - Its address is built under `2001:0000::/32` from the server's IPv4 address, flags, and the client's mapped port and IPv4 address, both stored with every bit inverted. - **Relays** connect Teredo clients to native IPv6. It works behind cone-style NATs and often fails behind symmetric ones (RFC 3489's older names for what RFC 4787 now calls mapping behaviours). - RFC 4380 calls it an **"IPv6 access of last resort"**: hosts SHOULD prefer native IPv6, a configured tunnel or 6to4 when they can. ## ISATAP — a site's IPv4 network as one link **ISATAP** (RFC 5214, Informational) connects dual-stack nodes **inside a site**. It treats the site's IPv4 network as a non-broadcast multi-access link. The interface identifier embeds the node's IPv4 address after `0000:5efe` (`0200:5efe` when the IPv4 address is globally unique). Hosts find ISATAP routers through a **Potential Router List** filled by manual configuration, a DNS name or a DHCPv4 option. ## Side by side | Mechanism | Specification | Outer transport | Far end found by | Crosses IPv4 NAT? | Scope | |---|---|---|---|---|---| | 6in4 (configured) | RFC 4213 | IP protocol 41 | Manual configuration | Generally not | Point to point | | 6to4 | RFC 3056; anycast relays deprecated by RFC 7526 | IP protocol 41 | IPv4 address inside `2002::/16` | Only if the NAT box is the 6to4 router | Internet, via relays | | Teredo | RFC 4380 | UDP, server port 3544 | Server qualification, address embeds mapping | Yes, cone-style NATs | Single host, last resort | | ISATAP | RFC 5214 | IP protocol 41 | IPv4 address in interface ID, router list | No | One site | ## Where they stand today RFC 6724's default address-selection table ranks 6to4 (precedence 30) and Teredo (5) **below IPv4** (35), so for a destination reachable both ways, a host using those defaults prefers plain IPv4 over either. Configured tunnels remain a legitimate tool between known endpoints; the automatic ones are mostly history that still shows up on hosts which enable them by default.

  • Why does 6to4 traffic to a native IPv6 host so often take a different path back?
    The outbound packet goes to whichever relay the 6to4 site uses, but the native IPv6 host returns traffic towards 2002::/16, which is routed to whichever relay advertises that prefix nearest to it. The two relays are usually different, often run by third parties, so either direction can fail independently — one reason RFC 7526 deprecated the anycast relay mechanism.
  • Why did Teredo use UDP rather than IP protocol 41 like the others?
    A port-translating NAT builds mappings from transport ports, and protocol 41 has none, so encapsulated packets cannot be mapped back to an inside host. RFC 4380 notes that TCP and UDP are the only protocols guaranteed to cross most NATs, and chose UDP because tunnelling over TCP performs poorly.

saying these in an interview costs you the question

  • RFC 7526 deprecated 6to4 entirely, including the 2002::/16 prefix.
  • Teredo carries IPv6 directly over IP protocol 41, like 6in4.
  • A host behind an IPv4 NAT can run 6to4 from its private address.
  • ISATAP joins separate IPv6 sites across the public internet.
  • A 6in4 tunnel learns its far endpoint from the destination address.