Summary

  • In 2001, 6to4 let a site derive a 2002::/16 IPv6 prefix from a globally unique IPv4 address and tunnel traffic across IPv4 without negotiating every tunnel in advance.
  • Anycast later made the relay look automatic, but forward and return paths could depend on different, unaccountable operators. Filtering, poor routes and default-on software turned convenience into recurring failure.
  • RFC 7526 deprecated the anycast relay mechanism in 2015. It did not deprecate basic unicast 6to4 or remove 2002::/16, a boundary that still matters when reading the registry today.

An address before an agreement

The most memorable part of 6to4 is a piece of arithmetic. Take a globally unique IPv4 address, express its 32 bits inside an IPv6 address, place them after the 2002 prefix, and a site has a /48. In the notation used by RFC 3056, the result was 2002:V4ADDR::/48. A network that did not yet have native IPv6 service could assign addresses from that prefix internally. At its boundary, a 6to4 router wrapped the IPv6 packet directly in an IPv4 packet using protocol 41.

Published in February 2001, RFC 3056 called this an optional interim mechanism. Its authors did not present it as the permanent architecture of IPv6. The appeal was narrower and very practical: sites could communicate over the IPv4 Internet without arranging a configured tunnel for every counterpart and without first obtaining an ordinary IPv6 prefix for this purpose. The globally unique IPv4 address acted as both raw material and locator.

That convenience had limits from the beginning. A private IPv4 address could not supply a globally meaningful 6to4 prefix. If the IPv4 address changed, the derived IPv6 prefix changed with it. And the mechanism still needed someone to carry packets between the 6to4 world and the native IPv6 world. Address construction had been automated; universal reachability had not.

The relay that disappeared from view

For traffic between two 6to4 sites, each endpoint’s embedded IPv4 address could tell the other side where to send the tunnel. Traffic between a 6to4 site and a native IPv6 destination was harder. It needed a relay that understood both worlds.

RFC 3068 supplied a remarkably simple answer: give relay routers a shared IPv4 anycast address, 192.88.99.1. A 6to4 router could send traffic toward that address, and ordinary IPv4 routing would choose a nearby relay advertising the route. The user no longer needed to discover or configure a particular gateway. A transition mechanism that had required some operational arrangement could now feel like a switch.

The switch concealed an asymmetry. The relay selected for outbound traffic did not have to be the relay used on the return path. A native IPv6 network sending toward 2002::/16 could choose a different relay, under a different operator, reached through a different routing policy. Neither relay had to know the other existed. Success depended on several organizations supplying compatible service, but the mechanism did not create a contract among them or a single owner of the round trip.

This was not a flaw visible in the address format. A valid 6to4 address could be generated exactly as documented while its packets met a firewall that discarded protocol 41, an absent relay advertisement, a poorly placed relay, or a return route that led into a black hole. The prefix could be correct and the experience still fail.

When fallback hid the bill

RFC 3964, published in 2004, concentrated on security. A relay had to consider whether the IPv4 source of a tunnel matched the IPv4 address embedded in the 6to4 source. Without filtering, forged traffic could be reflected, laundered through the transition system or made harder to attribute. The document did not claim that every relay was hostile. It showed that automatic encapsulation crossed trust boundaries that the address alone could not police.

By 2011, RFC 6343 could describe a broader operational record. It noted filters that blocked protocol 41, relays that were missing or unreachable, and paths that worked in one direction but not the other. It cited contemporary experiments in which 6to4 connection failure rates fell in roughly the 9–20 percent range. Those figures were not a global census, but they were large enough to turn a transition aid into a visible reliability problem.

The cost was often disguised rather than eliminated. A dual-stack application could try IPv6, wait while the 6to4 path failed, and eventually fall back to IPv4. To the user, the page might merely appear slow. To a software vendor, the obvious defensive response was to prefer working native paths and race alternatives, as later connection strategies such as Happy Eyeballs did. Each layer could reduce the symptom it exposed, while the relay system’s missing ownership remained unchanged.

Default enablement made the pattern persistent. A user who had never requested 6to4 could receive a derived address and an apparent IPv6 route from an operating system or edge device. RFC 6343 called that bad practice and recommended that 6to4 be disabled by default. The reversal was significant: the feature that had been attractive because it required little coordination now needed an informed decision to turn on.

Deprecating the shortcut, not rewriting the past

RFC 7526 formalized the retreat in May 2015. It deprecated the anycast 6to4 mechanism, moved RFC 3068 and the related RFC 6732 to Historic, and called for the anycast route and 192.88.99.1 relay service to be discontinued. Implementations were to disable 6to4 by default. The public shortcut no longer counted as recommended transition infrastructure.

The scope of that decision is easy to blur. RFC 7526 explicitly did not deprecate the basic unicast mechanism in RFC 3056, and it did not deprecate the 2002::/16 prefix. IANA’s current IPv6 Special-Purpose Address Registry still lists that block as 6to4. Registry presence records an architectural allocation; it does not promise that a public relay path is available or advisable.

The distinction explains why this history does not end with a deletion. The standards process could withdraw an operational recommendation and preserve the vocabulary needed to recognize old addresses, managed arrangements and residual systems. A network operator seeing 2002::/16 today should read it as evidence of the mechanism, not as evidence that the anycast service survived its review.