6to4: Automatic Tunneling with Address Embedding

What if IPv6 transition required no manual tunnel configuration at all? What if any site with a public IPv4 address could instantly gain IPv6 connectivity, automatically able to reach any other site with the same capability?

This was the vision behind 6to4: an automatic tunneling mechanism that embeds IPv4 addresses directly within IPv6 addresses, enabling tunnel endpoints to be derived algorithmically rather than configured manually. First standardized in 2001 (RFC 3056), 6to4 promised to accelerate IPv6 adoption by eliminating the configuration barrier.

The reality proved more complex. While 6to4's concept was elegant, operational challenges—asymmetric routing, unreliable relay routers, and NAT complications—led to significant reliability problems. Today, 6to4 is deprecated (RFC 7526), but understanding its mechanics is essential for network engineers who may encounter legacy deployments or need to understand why automatic tunneling proved problematic.

The core innovation of 6to4 is embedding the site's IPv4 address within its IPv6 prefix. This enables any router to determine the tunnel endpoint simply by examining the destination IPv6 address.

Address Structure

A 6to4 address uses the globally reserved 2002::/16 prefix, followed by the site's public IPv4 address encoded in hexadecimal:

6to4 Address Format:
2002:V4ADDR::/48

Where V4ADDR = 32-bit IPv4 address in hex

Example:
IPv4 address: 192.0.2.1
As hexadecimal: c0.00.02.01 → c000:0201
6to4 prefix: 2002:c000:0201::/48

Complete Address Breakdown

|  16 bits |    32 bits    |  16 bits  |       64 bits        |
+----------+---------------+-----------+----------------------+
|   2002   |  IPv4 in hex  | Subnet ID | Interface Identifier |
+----------+---------------+-----------+----------------------+
|  6to4    |  c000:0201    |   0001    |  host address bits   |
| prefix   | (192.0.2.1)   |           |                      |

The resulting hierarchy:

• Bits 1-16: Fixed prefix 2002::/16 (identifies 6to4)
• Bits 17-48: Site's public IPv4 address (enables tunnel endpoint derivation)
• Bits 49-64: Local subnet ID (site's internal subnetting)
• Bits 65-128: Interface identifier (host address within subnet)

Converting IPv4 to Hex

The conversion process is straightforward but error-prone by hand:

IPv4: 203.0.113.200

Step 1: Convert each octet to hex
  203 → CB (12*16 + 11 = 203)
  0   → 00
  113 → 71 (7*16 + 1 = 113)
  200 → C8 (12*16 + 8 = 200)

Step 2: Combine into 32-bit hex
  CB00:71C8

Step 3: Prepend 2002:
  2002:CB00:71C8::/48

This mathematical relationship between IPv4 and 6to4 addresses is what enables automatic endpoint derivation: given any 6to4 destination, the sender can extract the IPv4 tunnel endpoint without any pre-configuration.

6to4 enables three distinct communication scenarios, each with different mechanics:

Scenario 1: 6to4 Site to 6to4 Site

When both communicating sites use 6to4 addresses, tunneling is direct and symmetric.

Example:

• Site A: IPv4 192.0.2.1, IPv6 2002:c000:0201::/48
• Site B: IPv4 198.51.100.5, IPv6 2002:c633:6405::/48

Traffic Flow:

1. Host at Site A sends to 2002:c633:6405::100
2. Site A's 6to4 router examines destination: 2002:c633:6405...
3. Extracts IPv4: c633:6405 → 198.51.100.5
4. Encapsulates IPv6 in IPv4, destination 198.51.100.5
5. Packet traverses IPv4 Internet
6. Site B's 6to4 router de-encapsulates
7. Forwards to destination host

Return traffic follows the reverse path symmetrically.

Scenario 2: 6to4 Site to Native IPv6 (Via Relay)

This is where 6to4 gets complex. When a 6to4 site needs to reach a native IPv6 address (not 2002::/16), it cannot derive a tunnel endpoint—the destination has no embedded IPv4 address.

Solution: 6to4 Relay Routers

Relay routers advertise the 2002::/16 prefix into the native IPv6 Internet. They act as gateways between 6to4 and native IPv6:

1. 6to4 site sends to native IPv6 destination (e.g., 2001:db8::1)
2. 6to4 router doesn't recognize 2002::/16, needs relay
3. Packet is sent to a 6to4 relay via anycast address 192.88.99.1
4. Relay de-encapsulates and forwards natively to 2001:db8::1

The 192.88.99.1 Anycast Address:

RFC 3068 reserves 192.88.99.1 as the anycast address for 6to4 relays. Multiple relays worldwide announce this address; packets reach the topologically nearest relay.

IPv6 equivalent: 2002:c058:6301::/48 (192.88.99.1 in 6to4 format)

Scenario 3: Native IPv6 to 6to4 Site (Asymmetric Path)

Here's where serious problems emerge. When native IPv6 sends to 6to4:

1. Native IPv6 host sends to 2002:c000:0201::1
2. Packet routes through native IPv6 to some 6to4 relay
3. Relay sees 2002:c000:0201, extracts 192.0.2.1
4. Relay encapsulates and sends to 192.0.2.1
5. 6to4 site receives the packet

The Asymmetry Problem:

• Outbound (6to4 → native): Uses relay closest to 6to4 site
• Inbound (native → 6to4): Uses relay closest to native site

These are often different relays, potentially on different continents! If one direction's relay has problems, the bidirectional connection fails—yet troubleshooting only sees the working direction's path.

Despite being deprecated, understanding 6to4 router configuration helps in recognizing legacy deployments and understanding automatic tunneling concepts.

6to4 Router Requirements

A 6to4 border router must:

1. Have a public IPv4 address on an external interface
2. Support 6to4 tunneling mode (tunnel mode ipv6ip 6to4)
3. Configure the tunnel with the local IPv4 as source
4. Assign the derived 2002::/48 prefix to internal interfaces
5. Configure default route to 192.88.99.1 (relay anycast) for non-6to4 destinations

Conceptual Configuration Example

! Assuming external IPv4 is 192.0.2.1

! Create the 6to4 tunnel interface
interface Tunnel6to4
  tunnel source 192.0.2.1
  tunnel mode ipv6ip 6to4
  ipv6 address 2002:c000:0201::1/128
  
! Internal LAN interface
interface Ethernet0
  ipv6 address 2002:c000:0201:1::1/64
  
! Route to other 6to4 sites through tunnel
ipv6 route 2002::/16 Tunnel6to4

! Route to native IPv6 via relay anycast
ipv6 route ::/0 2002:c058:6301::1

Key points:

• Tunnel mode 'ipv6ip 6to4' tells the router to derive destination IPv4 from destination IPv6
• The 2002::/16 route ensures all 6to4 traffic goes through the tunnel
• The default route via 2002:c058:6301::1 (relay) handles native IPv6 destinations

Host-Based 6to4

Although 6to4 was primarily designed for routers, operating systems also implemented host-based 6to4. Windows XP/Vista/7 and early Linux kernels could act as their own 6to4 endpoints:

Windows:

netsh interface ipv6 6to4 set state state=enabled

Linux:

ip tunnel add tun6to4 mode sit remote any local 192.0.2.1
ip link set tun6to4 up
ip addr add 2002:c000:0201::1/16 dev tun6to4
ip route add ::/0 via ::192.88.99.1 dev tun6to4

However, host-based 6to4 was particularly unreliable because hosts typically don't have public IPv4 addresses—they're behind NAT. This led Microsoft and others to eventually disable 6to4 by default.

The Achilles' heel of 6to4 is its dependence on relay routers—and specifically, the lack of any reliable relay infrastructure.

Who Operates Relays?

Unlike DNS root servers (operated by designated organizations with formal responsibilities), 6to4 relays were operated by volunteers:

• Internet Service Providers (as a community service)
• Research networks
• Enthusiastic network operators
• Companies testing IPv6

There was no requirement, no SLA, no accountability. Relays could appear and disappear at will.

Anycast Instability

The 192.88.99.1 anycast approach created additional problems:

Path Selection Unpredictability:

• BGP selects the 'closest' relay by AS path, not by actual performance
• A relay with 192.88.99.1 announced from one AS might be congested while another is idle
• Route changes could instantly switch traffic to a different relay mid-connection

No Quality Guarantee:

• Some relays had limited bandwidth
• Some had high latency
• Some had intermittent connectivity
• All appeared identical to users

Measurement Studies

Research quantified the problem:

Study by Huston/APNIC (2011):

• Only ~15% of 6to4 connections succeeded reliably
• Average additional latency: 100-300ms compared to native
• Packet loss rates significantly higher than native IPv6

Study by Nikkhah et al. (2011):

• Documented cases of 6to4 traffic traversing intercontinental paths unnecessarily
• Found cases where relay selection changed multiple times per minute

The verdict: 6to4 wasn't just unreliable—it was unpredictably unreliable. Users experienced intermittent failures that were nearly impossible to diagnose.

Beyond operational problems, 6to4 introduced significant security risks that were difficult to mitigate.

Address Spoofing

Since 6to4 derives tunnel endpoints from addresses, spoofed addresses create spoofed tunnels:

Attack Scenario:

1. Attacker sends IPv6 packet with source 2002:c000:0201::1 (claiming to be from 192.0.2.1's network)
2. Destination responds to 2002:c000:0201::1
3. Response is tunneled to 192.0.2.1—the victim, not the attacker
4. Victim receives unsolicited tunnel traffic

This enables:

• Reflection attacks: Use victims' bandwidth to amplify DDoS
• Port scanning: Probe targets via unwitting 6to4 reflectors
• Anonymization: Attacks appear to come from legitimate 6to4 sites

Routing Attacks via Relay Manipulation

Rogue Relay Attack: Anyone can announce 192.88.99.1 and become a 6to4 relay. Malicious relays can:

• Intercept all 6to4 traffic for their BGP region
• Modify packets in transit
• Log all communications
• Selectively drop traffic
• Man-in-the-middle attack entire networks

Mitigation Difficulty: There's no way for 6to4 sites to verify they're using a legitimate relay. The anycast model means you get whatever relay BGP selects—you can't choose.

Firewall Bypass

IPv4 firewalls often don't inspect Protocol 41:

• 6to4 creates an 'invisible' IPv6 path through IPv4 networks
• Security policies for IPv4 don't apply to encapsulated IPv6
• Attackers can use 6to4 to tunnel past perimeter defenses

Enterprise Risk: Even if an enterprise blocks native IPv6, any host with a public IPv4 and 6to4 enabled can establish IPv6 connectivity—bypassing all IPv4 security controls.

Given the operational and security problems, the Internet Engineering Task Force (IETF) formally deprecated 6to4 in 2015.

RFC 7526: Deprecating 6to4

RFC 7526 ('Deprecating the Anycast Prefix for 6to4 Relay Routers') officially marked 6to4 as deprecated:

Key declarations:

• 6to4 relay anycast address (192.88.99.1) should no longer be advertised
• Network operators should not deploy new 6to4 relays
• Host operating systems should disable 6to4 by default
• Content providers should prefer native IPv6 over 6to4

Rationale from RFC 7526:

'The 6to4 relay routing model has proven to be fragile in practice, with various operational problems reported... The problems with 6to4 are not things that can be easily fixed. The fundamental problem is that 6to4 relies on a functional and ubiquitous deployment of 6to4 relay routers throughout the Internet. This condition has not been met and is unlikely to be met in the foreseeable future.'

What Replaced 6to4?

Native IPv6 is the preferred solution. As IPv6 deployment accelerated (now exceeding 40% globally), the need for tunneling mechanisms has decreased dramatically.

For sites still needing transition mechanisms:

• Tunnel brokers (like Hurricane Electric) provide reliable, configured tunneling
• Teredo offers NAT traversal (though also decreasingly used)
• NAT64/DNS64 enables IPv6-only clients to access IPv4 content
• 464XLAT provides IPv4 compatibility for IPv6-only mobile networks

Legacy Encounters

Despite deprecation, you may still encounter 6to4:

• Legacy routers with 6to4 enabled (need firmware updates)
• Old Windows machines never updated
• Historical documentation referencing 6to4
• Network troubleshooting involving 2002::/16 addresses

Response: Disable 6to4 wherever found. Replace with native IPv6 or properly managed tunneling.

Understanding 6to4's position among transition mechanisms helps clarify when each approach is appropriate (or was appropriate historically).

Comparison Matrix

Why 6to4 Failed Where Others Succeeded

Configured Tunnels succeed because:

• Both endpoints are explicitly known and managed
• No dependency on third-party relay infrastructure
• Clear accountability for tunnel operation

Tunnel Brokers succeed because:

• Professional operation with defined SLAs
• Clear point of contact for problems
• Consistent endpoint location (no anycast variability)

Native Dual-Stack succeeds because:

• No encapsulation overhead or complexity
• No relays or intermediaries
• Full ISP accountability for service

6to4 failed because:

• Relied on volunteer infrastructure
• Anycast created unpredictable paths
• No accountability for relay quality
• Security issues were unfixable without breaking the automatic nature