6to4 was an IPv6 transition mechanism designed to allow isolated IPv6 networks to communicate over the existing IPv4 Internet infrastructure. Defined in RFC 3056 (published in February 2001), it represented an ambitious attempt to solve a critical problem in the early 2000s: how to enable IPv6 adoption when most of the Internet still operated exclusively on IPv4.
The mechanism worked by automatically tunneling IPv6 packets through IPv4 networks without requiring explicit tunnel configuration. This "transparent" approach made 6to4 appealing for organizations and individuals wanting to experiment with IPv6 without waiting for their Internet service providers to offer native IPv6 support.
However, despite its theoretical elegance, 6to4 suffered from fundamental operational problems that ultimately led to its deprecation. Today, it serves as an important cautionary tale in protocol design and a reminder that automated solutions can sometimes create more problems than they solve.
At the heart of 6to4 lies a clever addressing scheme. The Internet Assigned Numbers Authority (IANA) allocated the IPv6 prefix 2002::/16 specifically for 6to4 usage. Any IPv6 address beginning with these first 16 bits (2002 in hexadecimal) immediately identifies itself as a 6to4 address.
The addressing mechanism works through direct embedding of IPv4 addresses into IPv6 address space. For any globally routable 32-bit IPv4 address assigned to a host or router, a corresponding 48-bit IPv6 prefix can be constructed by appending the IPv4 address to the 2002::/16 prefix.
Consider a concrete example: if a router has the public IPv4 address 192.0.2.4, the corresponding 6to4 prefix becomes 2002:c000:0204::/48. The middle section (c000:0204) represents the IPv4 address in hexadecimal notation: 192 = c0, 0 = 00, 2 = 02, 4 = 04.
This /48 prefix provides each 6to4 site with 65,536 /64 subnets—more than enough address space for most organizations. The automatic derivation from existing IPv4 addresses meant no registration or coordination with address registries was required, making deployment seemingly frictionless.
The tunneling mechanism operates through encapsulation. When an IPv6 host on a 6to4 network needs to send packets across an IPv4-only network, the 6to4 router encapsulates the IPv6 packet inside an IPv4 packet. The IPv4 header uses protocol number 41 to indicate that the payload contains an IPv6 packet.
When a 6to4 router receives an IPv6 packet destined for another 6to4 address, it examines the destination. If the address starts with 2002::/16, the router extracts the embedded IPv4 address (bits 17-48 of the IPv6 address) and uses it as the destination for the encapsulating IPv4 packet. The encapsulated packet then travels across the IPv4 Internet using standard routing until it reaches the destination IPv4 address, where another 6to4 router decapsulates it and delivers the IPv6 packet to the destination network.
This direct router-to-router tunneling works elegantly when both endpoints use 6to4. The challenge arose when 6to4 networks needed to communicate with the native IPv6 Internet—networks using globally routable IPv6 addresses that don't follow the 2002::/16 pattern.
To bridge 6to4 networks with the native IPv6 Internet, the protocol introduced the concept of relay routers. These specialized routers connect to both an IPv4 network and the native IPv6 Internet, acting as gateways between the two worlds.
A 6to4 relay router performs bidirectional translation:
2002::/16, the relay encapsulates them in IPv4 and forwards them across the IPv4 network to the appropriate 6to4 router.The original RFC 3056 assumed that relay routers would be manually configured. However, RFC 3068 (published June 2001) introduced an elegant solution: the anycast relay address 192.88.99.1. This well-known IPv4 address could be assigned to any number of 6to4 relay routers worldwide. When a 6to4 router needed to send traffic to the native IPv6 Internet, it would simply encapsulate the packet and send it to 192.88.99.1. Standard IPv4 routing would automatically deliver the packet to the nearest relay router (as determined by BGP routing policies).
The corresponding IPv6 anycast address 2002:c058:6301:: (derived from 192.88.99.1) allowed native IPv6 hosts to send traffic back to 6to4 networks through the nearest relay router.
This anycast approach eliminated the need for manual relay configuration, making 6to4 appear truly automatic. Unfortunately, this automation concealed serious operational problems.
In the early 2000s, 6to4 filled a genuine need. Native IPv6 deployment was virtually nonexistent among Internet service providers, yet the technical community recognized the urgency of transitioning from IPv4. The IPv4 address exhaustion problem was already visible on the horizon, and organizations needed ways to gain IPv6 experience.
6to4 allowed early adopters to obtain IPv6 connectivity immediately, without waiting for ISP support. Universities, research institutions, and technology companies used 6to4 to build the first generation of IPv6-enabled services. It provided valuable real-world experience with IPv6 networking and helped identify issues with the protocol stack implementations in various operating systems.
The mechanism also demonstrated that IPv6 could coexist with IPv4 infrastructure, providing proof-of-concept for the gradual transition model. Many lessons learned from 6to4 deployments informed the development of better transition mechanisms.
However, as 6to4 deployment spread beyond controlled experimental networks to general users and production systems, its fundamental weaknesses became increasingly apparent and problematic.
By the early 2010s, operational experience revealed that 6to4 caused more problems than it solved. RFC 6343, published in August 2011, documented extensive operational issues and provided advisory guidelines for deployment. Despite these warnings, problems continued to mount.
Finally, in May 2015, the IETF published RFC 7526, which deprecated the anycast prefix for 6to4 relay routers and requested that RFCs 3068 and 6732 be moved to Historic status. The document explicitly states that "experience with the 6to4 transition mechanism defined in RFC 3056 has shown that the mechanism is unsuitable for widespread deployment and use in the Internet when used in anycast mode."
Unpredictable path selection: The anycast mechanism provided no control over which relay router would handle traffic in either direction. The outbound path (6to4 to native IPv6) might use one relay, while the return path could use an entirely different relay. BGP routing policies, which determine anycast routing, don't necessarily produce symmetrical paths, leading to severe performance inconsistencies.
Unreliable relay availability: Anyone could announce the anycast prefix and become a relay router. While this seemed democratizing, it meant no quality guarantees. Relay routers might be misconfigured, overloaded, intermittently available, or operated by entities with insufficient resources or expertise. Some relay routers were deployed for testing and then abandoned while still announcing routes.
Impossible troubleshooting: When 6to4 connectivity failed or performed poorly, diagnosing the problem proved nearly impossible. Was the issue with the 6to4 router configuration? The IPv4 path? The relay router? The IPv6 path? The return relay? Users and network operators had no visibility into which relays their traffic used or any way to influence relay selection.
MTU and fragmentation problems: The encapsulation overhead reduced the effective MTU. When path MTU discovery failed (often due to misconfigured firewalls blocking ICMPv6), connectivity would mysteriously break for some packet sizes but not others.
Security concerns: The protocol provided no authentication or encryption. Malicious actors could announce the anycast prefix and intercept traffic. The automatic nature meant users had no awareness of which entities handled their traffic.
High failure rates: Studies showed that 6to4 connections failed at significantly higher rates than native IPv6 or properly configured tunnels. These failures caused end users to disable IPv6 entirely on their systems, creating a perverse outcome: a mechanism intended to promote IPv6 adoption was actually hindering it.
Content provider reluctance: The unreliability of 6to4 made content providers hesitant to offer IPv6 access. If a significant percentage of users experienced problems with IPv6 connectivity, providers would simply stick with IPv4-only operation.
While managed 6to4 tunnels with explicitly configured relay routers could avoid some anycast problems, they offered no advantages over traditional configured tunnels like 6in4. If operators needed to manually configure endpoints anyway, simpler mechanisms worked better. The complexity of 6to4's address derivation and encapsulation rules provided no benefit when the key selling point—automatic configuration—was abandoned.
Today, several better alternatives exist for organizations and individuals needing IPv6 connectivity:
The best solution is always native dual-stack IPv6 from your Internet service provider. Most major ISPs worldwide now offer IPv6 support. Native connectivity avoids all tunneling overhead, provides better performance, and eliminates the complexity of transition mechanisms.
For situations where ISP-provided IPv6 isn't available, tunnel broker services like Hurricane Electric's free tunnelbroker.net offer reliable 6in4 tunnels with explicit configuration. Unlike 6to4's anycast relays, tunnel brokers provide:
While tunnel brokers require manual configuration, this small administrative burden is vastly outweighed by the reliability improvement. The protocol is simpler (standard 6in4 tunneling) and the service operators are accountable.
For IPv6-only networks that need to access legacy IPv4 services, 464XLAT combines SIIT translation with NAT64. This modern approach allows providers to deploy IPv6-only infrastructure while maintaining IPv4 compatibility. Unlike 6to4, which tunnels IPv6 through IPv4, these mechanisms tunnel IPv4 through IPv6—reflecting the architectural inversion as IPv6 becomes primary.
Teredo was another transition mechanism, designed for situations where 6to4 couldn't work (behind NAT devices). However, it too suffered from reliability problems and has been deprecated. Its mention here serves mainly as a warning: automatic transition mechanisms generally proved problematic.
Mapping of Address and Port (MAP) represents a newer generation of transition technology, designed for ISPs to operate IPv6 networks while providing IPv4 as a service. These mechanisms entered the standards track in 2015, incorporating lessons learned from failed predecessors like 6to4.
If you're unsure whether your connection uses 6to4, native IPv6, or another mechanism, you can test your connectivity at test-ipv6.run. This tool performs comprehensive testing of both IPv4 and IPv6 connectivity, measures latency, and provides a detailed report of your network's IPv6 readiness.
The testing site can detect various IPv6 configurations and will alert you if it finds a broken or misconfigured IPv6 setup. If you discover you're using 6to4 (identifiable by 2002::/16 addresses), you should consider migrating to either native IPv6 from your ISP or a reliable tunnel broker service.
6to4 represented an ambitious attempt to solve the IPv6 transition problem through automation. Its elegant address embedding scheme and anycast relay mechanism seemed to offer a path to ubiquitous IPv6 deployment without requiring infrastructure upgrades or protocol coordination.
However, the Internet's fundamental characteristic—that it consists of independently operated networks with diverse policies, capabilities, and reliability levels—proved incompatible with 6to4's assumptions. Automatic relay selection produced unpredictable results. Anonymous, unaccountable relay operators provided unreliable service. Troubleshooting became impossible. High failure rates damaged IPv6's reputation.
The protocol's deprecation in 2015 formalized what operational experience had already demonstrated: some problems require human judgment, accountability, and explicit configuration. The "automatic" solution created more operational problems than it solved.
Today, 6to4 serves as an important historical lesson. Network protocols must account for operational realities, not just technical elegance. Transition mechanisms should prefer reliability over automation. And sometimes, the best path forward involves acknowledging that a seemingly clever solution doesn't work and moving on to better approaches.
For modern IPv6 deployment, the path is clear: pursue native dual-stack connectivity from your ISP, and use tunnel brokers as a temporary solution when necessary. The dream that 6to4 represented—universal automatic IPv6 connectivity—is finally being realized, but through native deployment rather than transition mechanisms.
For more information about IPv6 transition mechanisms and to test your current connectivity, visit test-ipv6.run.