6to4 Tunneling

This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers.  Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer.  The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6.  It is not intended as a permanent solution.

Any IPv4 node with a 6to4 tunnel configured and running can connect to any other IPv4 node with a 6to4 tunnel configured and running. This basically creates another address space, independent of the main IPv6 Internet (you might could call this the “6to4 Internet”). To communicate from a node with a working 6to4 tunnel to a regular IPv6 node on the real IPv6 Internet, you must make use of a 6to4 Relay Router. This is a node that contains both a 6to4 pseudo interface and a connection to the real IPv6 Internet, and can forward packets back and forth between the 6to4 Internet and the real IPv6 Internet.

A 6to4 Relay Router is a 6to4 Router than can forward packets between the 6to4 Internet and the real IPv6 Internet. It must have connections to both. Anyone could in theory create one of these and make it available. You would need to know the IPv4 address of the Relay Router to use it. You might even have to have your address permitted. RFC 3068 solves this problem by defining 192.88.99.1 as the official anycast address for 6to4 relay routers. This means that any 6to4 realy router should accept connections not only to its unicast IPv4 address, but also to that anycast address. All relay routers need to “announce” their existence to BGP routers, so that anyone connecting to that address will be steered to the one closest to them.

You can use 6to4 to obtain a single address (a /128 “block”), or to bring a /64 block into your network (the preferred model, to prevent an explosion of entries in the routing table).

6to4 uses an unusual addressing scheme. The first 16 bits contains the value 0x2002. The next 32 bits contains the public IPv4 address used for the tunnel. After that is the normal 16-bit Subnet ID and 64-bit Interface Identifier. If your public IPv4 address is 192.0.2.4, then your 48 bit prefix would be 2002:c000:0204::/48 (192 = 0xc0, 0=0x0, 2=0x2, 4=0x4). This means the entire block 2002::/16 is used for 6to4 addresses (and may not be used for native IPv6 nodes). If someone connects to your IPv6 server (that has a real IPv6 address), and their address starts with 2002, then they are using 6to4 through a 6to4 Relay Router.

Demonstration of 6to4 on Windows 7

Microsoft includes a 6to4 pseudo interface in Windows (since Vista), which is enabled by default. When you do an ipconfig /all, that interface will show up as one of the available interfaces (as long as it is enabled). This mechanism is of very limited use on an end-user node (e.g. one running Windows 7), since it is quite rare for such a node node to have a public IPv4 address. In fact, if your node’s IP address is private (one of the RFC 1918 blocks – 10/8, 172.16/12 or 192.168/16) those are not usable for 6to4, and Windows will report your 6to4 pseudo interface as “Media disconnected”, with no address.

However, if you can obtain one of the few remaining precious public IPv4 address and configure it on your Windows node, magically your 6to4 pseudo interface will come to life and automatically get a unique 6to4 address derived from your public IPv4 address. In my home, I have a modem/router that brings 5 public IP addresses into my network. I use one of those for hide mode NAT44 and 6in4 tunneling, and the others for servers behind BINAT. I temporarily disconnected one of those servers and plugged my notebook directly into my modem/router (outside of my firewall/NAT box). I now had something I haven’t seen in years – a Windows node with an actual public IPv4 address.

C:\Users\lhughes>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : lehnb6
   Primary Dns Suffix  . . . . . . . : hughesnet.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : hughesnet.local

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : 14-DA-E9-41-87-1B
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::cd68:e236:e882:5d5%11(Preferred)
   IPv4 Address. . . . . . . . . . . : 124.83.56.186(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.248
   Lease Obtained. . . . . . . . . . : Tuesday, August 27, 2013 6:33:58 PM
   Lease Expires . . . . . . . . . . : Friday, August 30, 2013 6:33:58 PM
   Default Gateway . . . . . . . . . : 124.83.56.185
   DHCP Server . . . . . . . . . . . : 124.83.56.185
   DNS Servers . . . . . . . . . . . : 124.106.5.2
                                       124.106.7.2
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter 6TO4 Adapter:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft 6to4 Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2002:7c53:38ba::7c53:38ba(Preferred)
   Default Gateway . . . . . . . . . : 2002:c058:6301::1
                                       2002:c058:6301::c058:6301
   DNS Servers . . . . . . . . . . . : 124.106.5.2
                                       124.106.7.2
   NetBIOS over Tcpip. . . . . . . . : Disabled

Note that we got public IPv4 address 124.83.56.186 with subnet mask 255.255.255.238 (/29). That is one of my precious public IPv4 addresses. The default gateway is 124.83.56.185.

C:\Users\lhughes>ping 2001:470:20::2

Pinging 2001:470:20::2 with 32 bytes of data:
Reply from 2001:470:20::2: time=196ms
Reply from 2001:470:20::2: time=182ms
Reply from 2001:470:20::2: time=181ms
Reply from 2001:470:20::2: time=182ms

Ping statistics for 2001:470:20::2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 181ms, Maximum = 196ms, Average = 185ms

Wow – it works! Let’s try pinging a node using a domain name:

C:\Users\lhughes>ping www.v6address.com

Pinging www.v6address.com [184.105.238.114] with 32 bytes of data:
Reply from 184.105.238.114: bytes=32 time=184ms TTL=51
Reply from 184.105.238.114: bytes=32 time=185ms TTL=51
Reply from 184.105.238.114: bytes=32 time=185ms TTL=51
Reply from 184.105.238.114: bytes=32 time=185ms TTL=51

Ping statistics for 184.105.238.114:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 184ms, Maximum = 185ms, Average = 184ms

This domain name has both A and AAAA records defined. For some reason, the A record is returned. Perhaps the DNS servers are not IPv6 compliant. Let’s try pinging a domain name that has only a AAAA record defined.

C:\Users\lhughes>ping www6.v6address.com

Pinging www6.v6address.com [2001:470:3d:200::114] with 32 bytes of data:
Reply from 2001:470:3d:200::114: time=194ms
Reply from 2001:470:3d:200::114: time=193ms
Reply from 2001:470:3d:200::114: time=192ms
Reply from 2001:470:3d:200::114: time=192ms

Ping statistics for 2001:470:3d:200::114:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 192ms, Maximum = 194ms, Average = 192ms

This time it works. Sounds like a DNS problem. Let’s surf to that domain name. It should show what address we are connecting from:

It shows our correct 6to4 address. Let’s try www.ipv6-test.com:

Looks pretty reasonable, except that if both are available, the browser chooses IPv4. One last test – www.test-ipv6.com.

A score of 0/10 doesn’t look so good. It seems to be having real problems with DNS. They have a good FAQ on 6to4.

I tested those two DNS servers. They appear to be able to resolve domain names correctly in nslookup. This could be yet another problem related to 6to4.

Analysis of IPv6 Connection Types over a Six Year Period

These statistics are from data supplied by Eric Vynce. They involve tens of thousands of connections to a site since 2008. During that time, 6to4 usage (as a percentage of all IPv6 traffic) has declined from about 22% to about 12%. The breakdown by year and connection type are as follows:

Year      Native    Teredo     6to4      Free.fr   ISATAP

Native connections had been around 20-25%, but suddenly jumped to almost 40% in 2013. Teredo is remaining at about 50% (with a peak in 2012 to 60%). 6to4 has decreased from about 22% to just over 12%. Free.fr users have been declining as a percent of the total, because the others have grown a lot. 6in4 and 6rd cannot be distinguished from native. ISATAP started small and has almost vanished.

Today, 6to4 usage has tapered off to nearly zero.

Security Issues with 6to4 Tunnels

RFC 3964, “Security Considerations for 6to4”, December 2004, contains a long list of serious problems with 6to4 tunnels, including the following

All 6to4 routers must accept and decapsulate IPv4 packets from every other 6to4 router, and from 6to4 relay routers. All 6to4 relay routers must accept connections from any native IPv6 node.

These requirements make it easy to spoof addresses by use of these routers, as well a denying service to legitimate users.

Anyone with access to a 6to4 router or 6to4 relay router could easily monitor or capture any unencrypted traffic going through them.

Summary

Due to the security issues and lack of any control over where your packets go, or even the possibility of obtaining a SLA (Service Level Agreement), I cannot recommend 6to4 tunnels for production networks. The benefits (automatic tunnel setup) do not justify the additional problems compared with basic 6in4 tunnels, which work great.