In networking, tunnels are a very useful concept. The basic idea is to prepend an "outer" IP header onto an existing IP packet (which has its own IP header), so that it is treated as a packet of the new header type. The entire original packet is treated as the payload of the outer IP header.

                                    |                           |
                                    |      Outer IP Header      |
                                    |                           |
+---------------------------+       +---------------------------+
|                           |       |                           |
|         IP Header         |       |         IP Header         |
|                           |       |                           |
+---------------------------+ ====> +---------------------------+
|                           |       |                           |
|                           |       |                           |
|         IP Payload        |       |         IP Payload        |
|                           |       |                           |
|                           |       |                           |
+---------------------------+       +---------------------------+

The point at which the outer IP header is added (encapsulation) is one "tunnel endpoint", and the point where it is removed (decapsulation) is the other "tunnel endpoint". In between the endpoints, the packet is in every way an IP packet of the type specified in the outer packet header, and will traverse any normal infrastructure of that type. This is key to getting access to the IPv6 Internet before your ISP offers IPv6 service to you.

Typically the point where encapsulation (or decapsulation) occurs is implemented as a "pseudo interface". For example, in SolidGate, the 6in4 tunnel interface is "gif0", which does not correspond to any physical interface. Tunnel endpoints are symmetric - they can encapsulate packets entering the tunnel and decapsulate packets from the other end that are exiting the tunnel. There is not a "server side" and "client side". There are just tunnel endpoints. A given node may have multiple endpoints connected to various other devices. If there are additional mechanisms for automatically setting up or tearing down tunnels (usually called Tunnel Brokers), those may be asymmetric, and have distinct client and server roles.

Recently someone posted a question on a forum asking "What ISPs in Malaysia have IPv6?". I replied "ALL OF THEM DO... just some of them will require use of tunnels."

Do not confuse tunnels with translation. In the IPv6 world, a tunnel is used to connect two isolated regions or "islands" of one IP family together, though an intervening region (or "ocean") of the other IP family. Once it leaves the tunnel, the original packet is exactly the same as when it entered the tunnel. No information is lost or gained. In between, it is a packet of the other IP family. In comparison, translation replaces the original IP header (of one IP family) with a new IP header (of the other IP family). Invariably information is lost, as there is not a one-to-one mapping of features from IPv4 to IPv6 or from IPv6 to IPv4. There are also major differences in ICMP versions, which must also be translated.

Tunneling is like giving a courier a sealed message to be unsealed upon delivery. It doesn't matter if the courier can read or speak English, so long as he can deliver the sealed message to the recipient, who does speak English. The received message is exactly what was intended.

Translation is like translating a message that is in English into Chinese for a courier to memorize (because he speaks only Chinese). If the recipient is Chinese, the translated message can be delivered in translated form. It may convey what was intended depending on the quality of the translation. If the recipient speaks only English, the message would have to be translated back into English upon receipt. The received message may be quite different from what was intended, depending on the accuracy of both translations. On the other hand, if you speak only English, and you are trying to understand a Chinese website, a tunnel is of no use to you - you need Google Translate.

Note that from the viewpoint of sender and recipient, the entire path through the tunnel (which may involve multiple hops) appears to be a single hop. The TTL (or Hop Limit) field of the original header will be decremented only once, regardless of how many hops the packet traverses inside the tunnel. The TTL (or Hop Limit) field of the outer header will be decremented by one for each hop inside the tunnel, as usual.

There are also some issues regarding ICMP error messages sent based on failures that happen inside the tunnel - for example, a tunneled packet expires while inside the tunnel - an ICMP "timeout" message (using the appropriate ICMP family for inside the tunnel) is returned to the encapsulating endpoint, which must in turn send a "timeout" message using the sender's ICMP protocol to the original sender. The packet will appear to have expired at the local tunnel endpoint.

If a packet expires in the path beyond the decapsulation point, an ICMP timeout message would have to be relayed back through the tunnel to the original sender. The Protocol (or Next Header) field still would contain 4 (for IPv4) or 41 (for IPv6), not a value indicating ICMP. This is because the entire IPv4 or IPv6 packet containing the ICMP message would be tunneled, not just the ICMP message. No translation is involved. ICMP messages originating outside of the tunnel are just normal IP traffic to a tunnel.

There is also an issue having to do with MTU and packet fragmentation. The tunnel is smaller than the outside network path by the size of the prepended packet header. For 6in4, if the outer MTU is 1500 bytes, inside the tunnel, the effective IPv6 MTU is only 1480 bytes (because each packet has an added IPv4 Packet Header added to it). This may lead to excessive fragmentation if not taken into account. This may be even more significant in 4in6 tunneling, because a 40 byte IPv6 basic header, and possibly one or more extension headers can be added to every tunneled packet. Of course this adds additional overhead as well, so throughput will be impacted. The extent of this impact depends on average packet size. If most of your packets are short, the impact can be significant.

A final aspect is that use of tunnels will confuse sites that use geolocation (determination of where a user is based on their IP address). For example, I use a 6in4 tunnel with one endpoint in the Philippines and one endpoint the U.S. Over IPv4 I appear to be in the Philippines. Over IPv6 I appear to be in the U.S.





Packets tunneled through IPv4

If you prepend an IPv4 Packet Header onto another packet, you set the Protocol field of the outer header to either 4, if the original packet is IPv4 ("IPv4 in IPv4" tunnel), specified in RFC 2003, "IP Encapsulation within IP", October, 1996, or 41, if the original packet is IPv6 ("6in4" tunnel), as specified in RFC 2473, "Generic Packet Tunneling in IPv6 Specification", December 1998. Because of this, "6in4" tunneled packets are often called "protocol 41 traffic" (not to be confused with "port 41 traffic").

The outer IPv4 header fields are set as follows:

Version: The value 4, for IPv4.

IHL: the length of the outer header in 32 bit words. Since this is a normal IPv4 header with no options, that is the value 5.

Total Length: The total length of the packet in bytes, which is the total length of the original packet in bytes, plus 20 (for the prepended IPv4 Packet Header). The resulting value must be less than 65,536, so the biggest packet you can tunnel through IPv4 is 65,515 bytes long.

TOS: the Type of Service field of the original packet header is copied to this.

Identification, Flags, Fragment Offset: Set as usual, based on whether packet needs to be fragmented or not, except that if the DF flag is set in the inner packet header (or if the inner packet is IPv6) it must be set in the outer packet header. If the DF flag is clear in the inner packet header, it may still be set in the outer packet header if desired.

Time To Live: Set as appropriate to deliver the encapsulated packet to the other tunnel endpoint.

Protocol: Set to 4 if the original packet is IPv4, or to 41 if the original packet is IPv6.

Header Checksum: normal 16-bit checksum of the outer packet header.

Source Address: the IPv4 address of the encapsulating tunnel endpoint.

Destination Address: the IPv4 address of the decapsulating tunnel endpoint.

Options: rarely used, but if used this will affect the IHL and Total Length fields of the outer packet header.


Packets tunneled through IPv6

The same idea can be done for traffic tunneled through IPv6 infrastructure. If you prepend an IPv6 Packet Header onto another packet, you set the Next Header field of the outer header to either 4, if the original packet is IPv4 ("4in6" tunnel) or 41, if the original packet is IPv6 ("6in6" tunnel). Both of these are specified in RFC 2473, "Generic Packet Tunneling in IPv6 Specification", December 1998.


                      | Original |                              |
                      |          |   Original Packet Payload    |
                      | Header   |                              |
                       <            Original Packet            >
 <Tunnel IPv6 Headers> <       Original Packet                 >

+---------+ - - - - - +-------------------------//--------------+
| IPv6    | IPv6      |                                         |
|         | Extension |        Original Packet                  |
| Header  | Headers   |                                         |
+---------+ - - - - - +-------------------------//--------------+
 <                          Tunnel IPv6 Packet                 >


The idea is basically the same as for tunnels over IPv4, except that the prepended header is an IPv6 Packet Header, with optional Extension Packet Headers. In this case, the encapsulated packet will traverse normal IPv6 infrastructure just like normal IPv6 packets. This mechanism is used to tunnel IPv4 to customers over native IPv6 in Dual Stack Lite (DS-Lite).

The fields of the outer IPv6 Packet Header are set as follows:

Version: the value 6 for IPv6

Traffic Class: depending on configuration of the encapsulating endpoint, this can be the TOC or Traffic Class of the original packet, or can be set to a pre-configured value.

Flow Label: depending on the configuration of the encapsulating endpoint, this can be a preconfigured value (typically 0).

Next Header: can be set to the header type of the next extension header, or if there are no extension headers, the protocol type of the original packet (4 for IPv4, 41 for IPv6). If there are extension headers, then the Next Header field of the final extension header is the protocol type of the original packet.

Hop Limit: Set to a preconfigured vlaue, sufficient for it to reach the decapsulating endpoint. The default value is whatever is advertised in Router Advertisements, which normally defaults to 64.

Source Address: the IPv6 address of the encapsulating endpoint.

Destination Address: the IPv6 address of the decapsulating endpoint.

Note: you can optionally include a Destination Options header extension to limit the maximum depth of encapsulation.


Generic Routing Encapsulation (GRE) Tunnels

Cisco created a similar technology called GRE Tunneling, that is specified in RFC 2784, "Generic Routing Encapsulation (GRE)", March 2000. it was updated by RFC 2890, "Key and Sequence Number Extensions to GRE", September 2000. GRE has similar capabilities to what was described above, but uses different mechanisms. Be aware that this is not just another name for the above tunnel mechanisms. For details, see the RFCs.


IPsec Tunnel Mode

Note that IPsec uses this concept in when it is used in Tunnel mode. In this case, the IP family of the outer header and inner header are the same (4in4 or 6in6). As above, the tunneled packet remains intact. Compare with IPSec Transport mode, in which the fields in the existing IP Header are modified. See the coverage of IPsec elsewhere for further details.


Security Issues

There are a number of security issues related to tunnels. Not all firewalls that do deep packet inspection are capable of looking inside tunnels. Legacy IPv4-only firewalls are particularly bad about not looking inside 6in4 tunnels, because the designers weren't familiar with IPv6 (or IPv6 didn't exist when the firewall was designed). Hackers often use tunnels to sneak malicious traffic past firewalls. It is good security practice to prevent any tunnel from crossing your border unless you specifically trust a given tunnel, and are certain you can identify it by endpoint addresses. Even then, your border gateway should examine the traffic inside the tunnel if possible (possibly to several levels of nesting). Of course, IPsec ESP traffic cannot be inspected without access to the encryption keys, so it is particularly dangerous.