6in4 Tunnel

6in4 tunnels (also called "manually configured tunnels") are the simplest way to tunnel IPv6 packets over IPv4. This mechanism is specified in RFC 2473, "Generic Packet Tunneling in IPv6 Specification", December 1998.

A 6in4 tunnel must be manually configured on both ends, and both ends require a globally routable ("public") IPv4 address to work. This public IPv4 address can be the same one you use for Hide Mode NAT44 on your border gateway. At the provider end, a single public IPv4 address can handle thousands of 6in4 tunnels. At the customer end, the public address must be on the WAN side of the node doing 6in4 tunneling, so it won't work well behind a typical home Customer Premises Equipment modem/router unless you can route the public address through it, or put it in "bridge mode". If you cannot disable the NAT44 in your modem/router, 6in4 tunneling may not be an option for you. It is possible that if your modem/route can be properly configured, only your ISP has the necessary credentials to do this. Tell them you need access to your public IPv4 address on the inside (LAN side) of your modem/router, or else replace your ISP modem/router with one that can be put into bridge mode, or can do 6in4 tunneling itself. You can route any size IPv6 netblock through a 6in4 tunnel, but /64 and /48 are the most common. 6in4 tunnels are not well suited to bringing IPv6 service to a single node in an IPv4-only network, since few end-user nodes have a public IPv4 address today.

All of the other schemes for tunneling IPv6 over IPv4 are based on 6in4 tunneling at bottom. They add various other mechanisms such as tunnel brokering (for automated setup) and/or NAT traversal (to allow use behind a NAT44 gateway).

Note that there is only one variant of "4in6" tunneling (the one specified in RFC 2473) since there is no NAT on IPv6 to cause problems.

Here is a diagram that shows the basic concept of 6in4 tunneling:

6in4 tunnel

In this diagram, on the right is the 6in4 tunneled IPv6 provider. They must have access to both the IPv4 Internet and the IPv6 Internet. There is a dual stack router (with a built-in 6in4 pseudo interface) connected to the IPv4 Internet on the WAN side, and their dual stack network on the LAN side.

On the left, there is a dual-stack LAN. It has an IPv4 prefix of 172.20/16 and an IPv6 prefix of 2001:db8:1:2::/64, which is determined by the tunneled IPv6 provider (note: if you get tunneled service from Hurricane Electric, your routed address block will probably start with 2001:470::/32, as that is their allocated block from ARIN). There is a border gateway (with a built-in 6in4 pseudo interface) connected to the IPv4 Internet on the WAN side, and your dual stack network on the inside.

In between is IPv4-only infrastructure. In my case, it is about 8,000 miles long, and is actually several different network providers and transit systems. It doesn't really matter to me what is in between, so long as I can access the IPv4 address at the tunnel provider.

When Alice sends an IPv6 packet (to www.kame.net), it is delivered via Ethernet to the default gateway (FW1 on this diagram). That is the local tunnel endpoint (from Alice's viewpoint). That gateway encapsulates her IPv6 packet by prepending an IPv4 Packet Header. The source address is the IPv4 address of the WAN interface of FW1. The destination address is the IPv4 address of the WAN interface of HE1 (the remote tunnel endpoint, from Alice's viewpoint). The tunneled packet travels over the intervening infrastructure and arrives at HE1. Router HE1 decapsulates the packet (by removing the IPv4 Packet Header) and routes the resulting IPv6 packet onto the service provider's dual stack network. From there, it routes the packet normally to the IPv6 destination (www.kame.net). The response from that node eventually makes its way back to HE1, which encapsulates it by prepending another IPv4 Packet Header to it. The source address is the WAN IPv4 address of HE1, and the destination address is the WAN IPv4 address of FW1. When the tunneled packet arrives at FW1 (after crossing all of that IPv4-only infrastructure between HE1 and FW1), it decapsulates the packet by removing the IPv4 Packet Header and routing the resulting IPv6 packet onto Alice's internal dual-stack LAN. FW1 delivers the IPv6 packet to Alice via Ethernet, where it displays a turtle in her browser, who is dancing for joy that all of this actually worked.

 

Capture of ICMPv6 Echo Request Inside 6in4 Tunnel

6in4 echo request

 

 

 

 

 

 

 

 

 

 

 

 

 

In this capture, you can see that the outer header is IPv4. The source address is 122.52.125.243 (the WAN interface of my local SolidGate firewall). The destination address is 184.105.238.1 (the WAN interface of the SolidGate firewall at our colo). The protocol type is 41 (IPv6).

The inner Packet Header is IPv6. The source address is 2001:470:3d:3000::2:1 (lawrence-pc, a Windows 7 node). The destination address is 2001:470:20::2 (a well-known DNS server at Hurricane Electric). The Next Header field contains 0x3a (ICMPv6).

The ICMPv6 message is type 128 (Echo Request). The ID is 0x1, sequence 0x52.

The IPv4 Header Length is 20 bytes. The IPv6 Header Length is 40 bytes. The IPv6 Payload Length (ICMPv6 message) is 40 bytes. This makes a total packet length of 100 bytes. Add the 14 bytes of Ethernet overhead and you get 114 bytes for the entire frame.

 

Capture of ICMPv6 Echo Reply Inside 6in4 Tunnel

6in4 echo reply

 

In this capture, you can see that the outer header is IPv4. The source address is 184.105.238.1 (the WAN interface of the SolidGate firewall at our colo). The destination address is 122.52.125.243 (the WAN interface of my local SolidGate firewall). The protocol type is 41 (IPv6).

The inner Packet Header is IPv6. The source address is 2001:470:20::2 (a well-known DNS server at Hurricane Electric). The destination address is 2001:470:3d:3000::2:1 (lawrence-pc, a Windows 7 node). The Next Header field contains 0x3a (ICMPv6).

The ICMPv6 message is type 129 (Echo Reply). The ID is 0x1, sequence 0x52.

The IPv4 Header Length is 20 bytes. The IPv6 Header Length is 40 bytes. The IPv6 Payload Length (ICMPv6 message) is 40 bytes. This makes a total packet length of 100 bytes. Add the 14 bytes of Ethernet overhead and you get 114 bytes for the entire frame.

 

Note: normally these two captures would have been difficult to obtain. We put a packet capture facility inside SolidGate to help in debugging technical issues. Packets captured with this can be downloaded and viewed in Wireshark.