6to4
termA 2001 IPv6 transition method that builds a site's IPv6 prefix from its public IPv4 address and tunnels across IPv4.
6to4 (RFC 3056) gave any site with a public IPv4 address a /48 under 2002::/16 and reached native IPv6 through relays, often found by anycast. High failure rates led RFC 7526 to deprecate those anycast relays in 2015, and RFC 6343 notes that rogue Router Advertisements often carry a 2002::/16 prefix.
The prefix is 2002 followed by the 32-bit IPv4 address, so, illustratively, 192.0.2.33 gives 2002:c000:221::/48, and the IPv4 tunnel endpoint for any 6to4 destination is read straight from its address; the packets travel as IP protocol 41. The IPv4 address must be one allocated by a registry, never RFC 1918 space. Traffic to native IPv6 goes through a relay, and the return path, attracted by a 2002::/16 route, often uses a different one.
That made it fragile. One experiment recorded failures in 9 to 20% of 6to4 connection attempts, often because filters near users dropped protocol 41, and dual-stack hosts hid it by falling back to IPv4 after 7 to 20 seconds. RFC 7526 (May 2015) deprecated the anycast relay address 192.88.99.1, but not 2002::/16 or unicast 6to4, and requires routers to ship with 6to4 disabled; RFC 6724 ranks 6to4 below native IPv4.
Python's ipaddress returns the embedded IPv4 from the sixtofour property, and the IPv6 Toolkit labels 2002::/16 as 6to4 without extracting it.
Also known as: 6to4 tunnel, 6to4 relay, 2002::/16, 192.88.99.1, rfc 3056
Sources
- RFC 3056, Connection of IPv6 Domains via IPv4 Clouds, February 2001: abstract and sections 2 and 5.3 (read 2026-10-18)
- RFC 7526, Deprecating the Anycast Prefix for 6to4 Relay Routers, May 2015: sections 1 to 5 (read 2026-10-18)
- RFC 6343, Advisory Guidelines for 6to4 Deployment, August 2011: section 3 (read 2026-10-18)
- RFC 6724, Default Address Selection for Internet Protocol Version 6 (IPv6), September 2012: section 2.1 and appendix B (read 2026-10-18)