## 2 Introduction to IPv6
### Transition Methods
#### 2.3.3 Tunnel  
Tunnels for IPv6 were primarily developed to be able to cross IPv4-only sections of a network during transition. Several tunneling techniques have been specified in the last years. This section gives an overview of the currently most prominent tunneling techniques. Since tunnels add complexity and transparency to the network, they are considered temporary tools for IPv6 deployment. If possible, tunnels should be avoided and disabled as soon as they are not needed anymore [3, 47]. Generally, there are two types of tunnels: Tunnels which have to be manually configured and automatic tunnels. From  
Figure 3: IPv4 embedded IPv6 address formats [45]. a security point of view, automatic tunneling is questionable and should always be turned off if it is not used [47]. Configured tunnels have to be set up and managed manually by an administrator and are specified in RFC 4213 [46]. For tunneling IPv6 through an IPv4 network the protocol 41 is used and has to be enabled on the route. In case that IPv4 packets are tunneled through an IPv6 network, Generic Routing Encapsulation GRE or Multiprotocol Label Switching MPLS can be used. Configured tunnels do not scale as well as automatic tunnels because administrators have to set up and shut down tunnels manually every time when changes are necessary. All the following tunnels are automatic tunnels. 6 to4 is specified in RFC 3056 [48]. This technique is used for global reachability and tunneling through the IPv4 Internet. Since the publicly available prefix 2002:/16 is used, a globally unique IPv4 prefix is needed. Networks that want to connect to each other need to have access to the same IPv4 network and set up a 6 to4 relay router at the border of both sites. 6 to4 is in use in productive systems. The technique, however, has some security implications and should only be used if the ISP does not provide IPv6 prefixes. Among the security threats are source spoofing and Denial of Service (DoS) attacks. 6 over4 is specified in RFC 2529 [49]. It depends on IPv4 multicast as virtual link layer and thus is intended for use within a site rather than for connecting an IPv6 node with the rest of the Internet. IPv4 multicast must be enabled in the entire network. IPv6 interfaces are assigned a unicast address with a valid 64 bit prefix and a 32 bit IPv4 address as suffix. Additionally, they are assigned a link-local address. So far, this method is not widely used. 6 rd (IPv6 rapid deployment) is similar to 6 to4 but does not use the publicly available prefix. It requires a globally routable IPv6 prefix. This technique is specified in RFC 5969 [50]. It is primarily meant for use by ISPs as a fast deployment of IPv6 to their customers. The IPv6 address is constructed by the network prefix in concatenation with a prefix-reduced customer IPv4 address. The calculation of the prefix is automated and conform with automatic reset of IPv4 addresses because it recalculates the prefix every time. Teredo was developed by Microsoft and later approved by the IETF in RFC 4380 [51]. It is meant to solve the problem of tunneling IPv6 through NATs or multiple layers of NATs by using the User Datagram Protocol (UDP) instead of IP protocol 41. It can be used as \"technology of last resort\" [3] for deployment of IPv6 hosts behind NAT. Teredo provides automatic tunneling and uses addresses of the following type: _2001:0000::/32_ + Teredo Server IPv4 address (globally unique) + Flags + Port + Client IPv4 address. However, Teredo has many security issues. It requires UDP port 3544 to be open, and rogue Teredo servers could be used for man-in-the-middle attacks. DoS and distributed DoS could also be issues [51]. Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is used for connecting isolated IPv6 hosts within a site network. ISATAP is specified in RFC 5214 [52]. This technique is meant for an early stage IPv6 transition, when small IPv6 islands exist. It is supported by almost all operating systems which feature IPv6.